From report at bugs.python.org  Fri Oct  1 04:19:49 2021
From: report at bugs.python.org (kubat aytekin)
Date: Fri, 01 Oct 2021 08:19:49 +0000
Subject: [New-bugs-announce] [issue45338] Add key argument to
 collections.Counter
Message-ID: <1633076389.73.0.735065140955.issue45338@roundup.psfhosted.org>


New submission from kubat aytekin <kubataytekin at yahoo.com.tr>:

Counter has become the default tool for counting occurences of objects in an iterable. However by construction it only works on hashable objects as it is a subclass of dict. Would it be possible to implement a "key=" keyword argument as in sort etc.? 

Here's a stackoverflow question wherein either map or implementing a hash method was proposed:
https://stackoverflow.com/questions/69401713/elegant-way-of-counting-items-in-a-list-by-enum-value-in-python

----------
components: Library (Lib)
messages: 403002
nosy: kubataytekin
priority: normal
severity: normal
status: open
title: Add key argument to collections.Counter
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  1 06:37:53 2021
From: report at bugs.python.org (Erick)
Date: Fri, 01 Oct 2021 10:37:53 +0000
Subject: [New-bugs-announce] [issue45339]
 concurrent.future.ThreadPoolExecutor should parameterize class used for
 threads
Message-ID: <1633084673.43.0.269469120691.issue45339@roundup.psfhosted.org>


New submission from Erick <erick.peirson at gmail.com>:

Currently the only way to use a class other than `threading.Thread` with `concurrent.futures.ThreadPoolExecutor` is to extend `ThreadPoolExecutor` and override the private method `_adjust_thread_count()`. 

For example, suppose I have a class that applies some custom logic when running code in a new thread:

```
class MyThread(threading.Thread):
    def run(self):
        with some_important_context():
            super().run()
```

Using this class with `ThreadPoolExecutor` requires me to write the following code:

```
class MyThreadPoolExecutor(ThreadPoolExecutor):
    def _adjust_thread_count(self):
        # if idle threads are available, don't spin new threads
        if self._idle_semaphore.acquire(timeout=0):
            return

        # When the executor gets lost, the weakref callback will wake up
        # the worker threads.
        def weakref_cb(_, q=self._work_queue):
            q.put(None)

        num_threads = len(self._threads)
        if num_threads < self._max_workers:
            thread_name = '%s_%d' % (self._thread_name_prefix or self,
                                     num_threads)
            t = MyThread(name=thread_name, target=_worker,
                         args=(weakref.ref(self, weakref_cb),
                               self._work_queue,
                               self._initializer,
                               self._initargs))
            t.start()
            self._threads.add(t)
            _threads_queues[t] = self._work_queue


with MyThreadPoolExecutor(max_workers=1) as executor:
    future = executor.submit(pow, 323, 1235)
    print(future.result())
```

That's a bummer, because now I have to maintain this method if there are upstream fixes/changes. I also can't count on it existing in the future, since it's a private method. 

In other words, `ThreadPoolExecutor` is not composable, and extending it to use a custom `Thread` class is neither safe nor maintainable.

Here's what I'd like to be able to do instead:

```
with ThreadPoolExecutor(max_workers=1, thread_class=MyThread) as executor:
    future = executor.submit(pow, 323, 1235)
    print(future.result())
```

----------
components: Library (Lib)
messages: 403007
nosy: erickpeirson
priority: normal
pull_requests: 27040
severity: normal
status: open
title: concurrent.future.ThreadPoolExecutor should parameterize class used for threads
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  1 07:21:17 2021
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 01 Oct 2021 11:21:17 +0000
Subject: [New-bugs-announce] [issue45340] Lazily create dictionaries for
 plain Python objects
Message-ID: <1633087277.57.0.188806648124.issue45340@roundup.psfhosted.org>


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

A "Normal" Python objects is conceptually just a pair of pointers, one to the class, and one to the dictionary.

With shared keys, the dictionary is redundant as it is no more than a pair of pointers, one to the keys and one to the values.

By adding a pointer to the values to the object, or embedding the values in the object, and fetching the keys via the class, we can avoid creating a dictionary for many objects.

See https://github.com/faster-cpython/ideas/issues/72 for more details.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 403010
nosy: Mark.Shannon, methane
priority: normal
severity: normal
status: open
title: Lazily create dictionaries for plain Python objects
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  1 09:43:03 2021
From: report at bugs.python.org (Steven Hsu)
Date: Fri, 01 Oct 2021 13:43:03 +0000
Subject: [New-bugs-announce] [issue45341] Update "Python Package Index" in
 Docs
Message-ID: <1633095783.18.0.61571389025.issue45341@roundup.psfhosted.org>


New submission from Steven Hsu <hsuhaochun at gmail.com>:

The full name of PyPI is "Python Package Index" at https://pypi.org/ , but it is still "Python Packaging Index" in Docs (https://github.com/python/cpython/blob/main/Doc/distributing/index.rst).

Therefore, an update of the term in the Docs is suggested.

The objective of the update was related to the translation work. ("Package "and "Packaging" have different translations in zh-tw language).

Thanks for review.

----------
assignee: docs at python
components: Documentation
messages: 403014
nosy: StevenHsuYL, docs at python
priority: normal
severity: normal
status: open
title: Update "Python Package Index" in Docs
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct  1 11:51:56 2021
From: report at bugs.python.org (shreya)
Date: Fri, 01 Oct 2021 15:51:56 +0000
Subject: [New-bugs-announce] [issue45342] wrap_socket fails when
 load_cert_chain is called without setting the ciphers
Message-ID: <1633103516.08.0.850805825875.issue45342@roundup.psfhosted.org>


New submission from shreya <shreya.dhareshwar at gmail.com>:

Example:

self.socket = ssl.wrap_socket(socket.socket(self.address_family, self.socket_type),
                                              keyfile=keys, certfile=certs, server_side=True, ciphers="DEFAULT at SECLEVEL=1")

Gives the following exception -

 File "ssl.py", line 1402, in wrap_socket
    context.load_cert_chain(certfile, keyfile)
ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:4023)

----------
assignee: christian.heimes
components: SSL
messages: 403019
nosy: christian.heimes, shreya1312
priority: normal
pull_requests: 27046
severity: normal
status: open
title: wrap_socket fails when load_cert_chain is called without setting the ciphers
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  1 16:04:55 2021
From: report at bugs.python.org (Illia Volochii)
Date: Fri, 01 Oct 2021 20:04:55 +0000
Subject: [New-bugs-announce] [issue45343] Update bundled pip to 21.2.4 and
 setuptools to 58.1.0
Message-ID: <1633118695.71.0.173391630315.issue45343@roundup.psfhosted.org>


Change by Illia Volochii <illia.volochii at gmail.com>:


----------
components: Distutils
nosy: dstufft, eric.araujo, illia-v
priority: normal
severity: normal
status: open
title: Update bundled pip to 21.2.4 and setuptools to 58.1.0
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct  1 20:10:31 2021
From: report at bugs.python.org (Nate Woods)
Date: Sat, 02 Oct 2021 00:10:31 +0000
Subject: [New-bugs-announce] [issue45344] Have zipapp respect
 SOURCE_DATE_EPOCH
Message-ID: <1633133431.67.0.788780206005.issue45344@roundup.psfhosted.org>


New submission from Nate Woods <big.nate.w at gmail.com>:

I have a small patch that would make zipapp respect SOURCE_DATE_EPOCH.  This will ensure the zip bundles created by zipapp have consistent hashes regardless of when the source files were last touched.  This idea came to my attention recently when I came across: https://reproducible-builds.org/

I can convert my changes to a PR if it's deemed interesting or useful, but I would like to respect the core maintainers time.  Please let me know if these changes are not desired or not worth while and I'll seek to find somewhere else to put them.

Also, I'm completely new here, so I apologize if there is anything I'm doing against protocol. I didn't find any issues in the tracker pertaining to this, and it seemed small and contained enough to be something I could try out.

Hopefully this issue finds the maintainers well.

----------
components: Library (Lib)
files: zipapp-respect-source-date-epoch.patch
keywords: patch
messages: 403041
nosy: bign8
priority: normal
severity: normal
status: open
title: Have zipapp respect SOURCE_DATE_EPOCH
type: enhancement
versions: Python 3.11
Added file: https://bugs.python.org/file50320/zipapp-respect-source-date-epoch.patch

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

From report at bugs.python.org  Sat Oct  2 09:23:37 2021
From: report at bugs.python.org (Code7737)
Date: Sat, 02 Oct 2021 13:23:37 +0000
Subject: [New-bugs-announce] [issue45345] Equalized lists depend to each
 other after equalizing
Message-ID: <1633181017.0.0.77331595707.issue45345@roundup.psfhosted.org>


New submission from Code7737 <Code7737 at yandex.ru>:

When you make two lists same by using "=" and then change one of them, other changes too

----------
files: Test.py
messages: 403052
nosy: Code7737
priority: normal
severity: normal
status: open
title: Equalized lists depend to each other after equalizing
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50321/Test.py

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

From report at bugs.python.org  Sat Oct  2 10:17:26 2021
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 02 Oct 2021 14:17:26 +0000
Subject: [New-bugs-announce] [issue45346] Some "truthy" crept in
Message-ID: <1633184246.2.0.0169690019034.issue45346@roundup.psfhosted.org>


New submission from Stefan Pochmann <stefan.pochmann at gmail.com>:

Python consistently says true/false, not truthy/falsy. But a few "truthy" have crept in now:

https://github.com/python/cpython/search?q=truthy
- Two in Doc/reference/compound_stmts.rst
- One in Doc/library/ast.rst
- One in Lib/test/test_builtin.py

Evidence for consistent true/false usage, if needed:
https://docs.python.org/3/library/stdtypes.html#truth-value-testing
https://docs.python.org/3/library/stdtypes.html#boolean-operations-and-or-not
https://docs.python.org/3/reference/compound_stmts.html#the-if-statement
https://docs.python.org/3/reference/compound_stmts.html#the-while-statement
https://docs.python.org/3/reference/expressions.html#boolean-operations

----------
assignee: docs at python
components: Documentation
messages: 403056
nosy: Stefan Pochmann, docs at python
priority: normal
severity: normal
status: open
title: Some "truthy" crept in
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Oct  2 13:01:42 2021
From: report at bugs.python.org (Daniele Varrazzo)
Date: Sat, 02 Oct 2021 17:01:42 +0000
Subject: [New-bugs-announce] [issue45347] datetime subject to rounding?
Message-ID: <1633194102.6.0.241729336774.issue45347@roundup.psfhosted.org>


New submission from Daniele Varrazzo <daniele.varrazzo at gmail.com>:

I found two datetimes at difference timezone whose difference is 0 but which don't compare equal.

Python 3.9.5 (default, May 12 2021, 15:26:36) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime as dt
>>> from zoneinfo import ZoneInfo
>>> for i in range(3):
...     ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
...     print(ref.astimezone(ZoneInfo(key='Europe/Rome')) == ref.astimezone(dt.timezone(dt.timedelta(seconds=3600))))
... 
True
False
True
>>> for i in range(3):
...     ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
...     print(ref.astimezone(ZoneInfo(key='Europe/Rome')) - ref.astimezone(dt.timezone(dt.timedelta(seconds=3600))))
... 
0:00:00
0:00:00
0:00:00

Is this a float rounding problem? If so I think it should be documented that datetimes bewhave like floats instead of like Decimal, although they have finite precision.

----------
components: Library (Lib)
messages: 403059
nosy: piro
priority: normal
severity: normal
status: open
title: datetime subject to rounding?
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct  2 18:59:27 2021
From: report at bugs.python.org (Eddie Caraballo)
Date: Sat, 02 Oct 2021 22:59:27 +0000
Subject: [New-bugs-announce] [issue45348] math.log(243, 3) value issue
Message-ID: <1633215567.13.0.276827161808.issue45348@roundup.psfhosted.org>


New submission from Eddie Caraballo <eddiemichaelc at gmail.com>:

math.log(243, 3) should result in 5.0, but instead results in 4.9999...

Can be worked around via base conversion (math.log10(243) / math.log10(3))

----------
components: Library (Lib)
messages: 403065
nosy: eddiemichaelc
priority: normal
severity: normal
status: open
title: math.log(243, 3) value issue
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct  2 21:02:54 2021
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 03 Oct 2021 01:02:54 +0000
Subject: [New-bugs-announce] [issue45349] configparser.ConfigParser: 2
 newlines at end of file (EOF)
Message-ID: <1633222974.18.0.394436455251.issue45349@roundup.psfhosted.org>


New submission from Bo?tjan Mejak <bostjan.xperia at gmail.com>:

In every Python version that I've tested, writing a config.ini file (utilizing configparser.ConfigParser), the result is such that the config.ini file has 2 newlines at the end of the file.

The problem is that source code editors like Sublime Text, or IDEs like PyCharm, already insert a newline at the end of a file, but then configparser.ConfigParser 
(or maybe the Python's write() function?)  insert its own as well.

Is it possible to fix this behavior?

----------
components: Library (Lib)
messages: 403069
nosy: PythonEnthusiast
priority: normal
severity: normal
status: open
title: configparser.ConfigParser: 2 newlines at end of file (EOF)
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/issue45349>
_______________________________________

From report at bugs.python.org  Sun Oct  3 00:13:54 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Oct 2021 04:13:54 +0000
Subject: [New-bugs-announce] [issue45350] configure incorrectly ignores
 pkg-config information for libffi and Tcl/Tk in 3.10
Message-ID: <1633234434.7.0.199943482554.issue45350@roundup.psfhosted.org>


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

./configure supports using the system or third-party-supplied pkg-config utility to find or override the default location of header and library files when building a few C extensions in the standard library, namely from OpenSSL for the _ssl module, libffi for ctypes, and, new in 3.10, Tcl/Tk for _tkinter (bpo-42603). However, currently for 3.10.0, pkg-config usage is broken for libffi and Tcl/Tk (but not OpenSSL). When running ./configure, there is an unexpected warning that is easily overlooked:

[...]
checking for --with-libs... no
./configure: line 10545: PKG_PROG_PKG_CONFIG: command not found
checking for --with-system-expat... no
[...]

PKG_PROG_PKG_CONFIG is a macro provided by GNU Autotools that is supposed to be in aclocal.m4. Unfortunately, it appears to have been inadvertently deleted in 2fc857a5721a5b42bcb696c9cae1bbcc82a91b17 (PR 25860) probably due to an autoconf version mismatch. The net effect is that the configure variable PKG_CONFIG, the location of the pkg-config utility, is undefined so tests in configure for the location of libffi and of Tcl and Tk do not take into account any pkg-config info and use any default locations (i.e. /usr/include). For most builds, that likely still produces the desired results. But it won't if a builder is trying to override these locations or is building on a platform with different default or is using a third-party package manager and pkg-config to supply libraries.  Note, the _ssl module builds are not affected by this problem as the AX_CHECK_OPENSSL macro in aclocal.m4 does not depend on PKG_PROG_PKG_CONFIG to find pkg-config.

It appears that the problem can be worked around by explicitly setting the PKG_CONFIG build variable when invoking configure, something like:

  ./configure [...] PKG_CONFIG=$(which pkg-config)

But the PR 25860 changes to aclocal.a4 should be carefully reviewed and the pkg-config related deletes restored; there might be other problems, too. This is not the first time we've been caught up by unexpected autoconf changes and, as is clear here, it is too easy for them to go unnoticied. Perhaps we should try to figure out how to reduce those risks.

----------
assignee: pablogsal
components: Build
messages: 403076
nosy: ned.deily, pablogsal
priority: high
severity: normal
stage: needs patch
status: open
title: configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun Oct  3 07:58:21 2021
From: report at bugs.python.org (Olaf van der Spek)
Date: Sun, 03 Oct 2021 11:58:21 +0000
Subject: [New-bugs-announce] [issue45351] List all sockets in TCP echo
 server using streams
Message-ID: <1633262301.08.0.953751090869.issue45351@roundup.psfhosted.org>


New submission from Olaf van der Spek <olafvdspek at gmail.com>:

Replace:
addr = server.sockets[0].getsockname()
print(f'Serving on {addr}')

By:
for socket in server.sockets: 
  addr = socket.getsockname()
  print(f'Serving on {addr}')

https://docs.python.org/3/library/asyncio-stream.html

----------
assignee: docs at python
components: Documentation
messages: 403084
nosy: docs at python, olafvdspek
priority: normal
severity: normal
status: open
title: List all sockets in TCP echo server using streams

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

From report at bugs.python.org  Sun Oct  3 09:12:33 2021
From: report at bugs.python.org (Patrick Reader)
Date: Sun, 03 Oct 2021 13:12:33 +0000
Subject: [New-bugs-announce] [issue45352] Move documentation for typed
 generic forms of standard collections to collections.abc
Message-ID: <1633266753.15.0.403359406575.issue45352@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

Currently the documentation for the generic forms (e.g. what the parameters in square brackets mean) of standard collections (e.g. collections.abc.Generator), is still on the typing page (https://docs.python.org/3.10/library/typing.html#typing.Generator).

This is from before PEP 585 was implemented, which deprecated the ones in typing in favour of the aliases in collections.abc. The documentation for these should be moved, or at least linked to, in the collections.abc page. The same applies to builtin types like list which can now also be directly parameterised.

In the case of Generator, for example, the text at https://docs.python.org/3.10/library/typing.html#typing.Generator, "A generator can be annotated...", should be moved to 
https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Generator.

I chose Generator as an example, because it has three parameters YieldType, SendType, ReturnType whose order I can't remember and need to look up. For some types, such as Iterable, the meaning of the parameter is quite straightforward, so little documentation is needed (so https://docs.python.org/3.10/library/typing.html#typing.Iterable just says "A generic form of https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Iterable"), but there should still be a note on the collections.abc page that it can be parameterised.

Perhaps there should also be a message saying "new in version 3.9: this can now be parameterised" on each ABC collection.

I can see that it might not be desirable to have this information scattered across other pages, because it is fundamentally about typing and pretty unrelated to builtin documentation, so it may be preferable to just link to the typing page rather than move the text. But since the old generics are deprecated, if they are removed, the documentation must be preserved.

----------
assignee: docs at python
components: Documentation
messages: 403085
nosy: docs at python, pxeger
priority: normal
severity: normal
status: open
title: Move documentation for typed generic forms of standard collections to collections.abc
type: enhancement

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

From report at bugs.python.org  Sun Oct  3 10:36:51 2021
From: report at bugs.python.org (Idan Cohen)
Date: Sun, 03 Oct 2021 14:36:51 +0000
Subject: [New-bugs-announce] [issue45353] sys.modules: dictionary changed
 size during iteration
Message-ID: <1633271811.32.0.73963856747.issue45353@roundup.psfhosted.org>


New submission from Idan Cohen <idan57 at gmail.com>:

Hi,

When iterating over sys.modules it might be that because of lazy loading or that other module reload is being reloaded (even if sys.modules.copy() is being used) you will get:

"RuntimeError: dictionary changed size during iteration"

The usage of sys.modules and iteration over it is used in many places

I know that this is a known issue but didn't find any solution or fix for that. Also, if there is some work around that might solve this, I would appreciate it.

Thanks,
Idan

----------
components: Library (Lib)
messages: 403089
nosy: idan57
priority: normal
severity: normal
status: open
title: sys.modules: dictionary changed size during iteration
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct  3 10:42:28 2021
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 03 Oct 2021 14:42:28 +0000
Subject: [New-bugs-announce] [issue45354] test_winconsoleio fails on Windows
 11
Message-ID: <1633272148.77.0.0556992237798.issue45354@roundup.psfhosted.org>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

It appears there have been some console related changes in Windows 11

======================================================================
ERROR: test_open_name (test.test_winconsoleio.WindowsConsoleIOTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Jeremy\source\repos\cpython\lib\test\test_winconsoleio.py", line 95, in test_open_name
    f = open('C:/con', 'rb', buffering=0)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'C:/con'

======================================================================
FAIL: test_conout_path (test.test_winconsoleio.WindowsConsoleIOTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Jeremy\source\repos\cpython\lib\test\test_winconsoleio.py", line 118, in test_conout_path
    self.assertIsInstance(f, ConIO)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: <_io.FileIO name='C:\\Users\\Jeremy\\AppData\\Local\\Temp\\tmpoqx235b0\\CONOUT$' mode='wb' closefd=True> is not an instance of <class '_io._WindowsConsoleIO'>

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

----------
components: Tests, Windows
messages: 403090
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_winconsoleio fails on Windows 11
type: behavior

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

From report at bugs.python.org  Sun Oct  3 13:00:44 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Oct 2021 17:00:44 +0000
Subject: [New-bugs-announce] [issue45355] Use sizeof(_Py_CODEUNIT) instead
 of literal 2 for the size of the code unit
Message-ID: <1633280444.05.0.146974944058.issue45355@roundup.psfhosted.org>


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

Some C code in 3.10+ uses literal 2 for the size of the code unit. It should use sizeof(_Py_CODEUNIT) instead.

1. It is self-documented and allows to distinguish this 2 from other 2 constants.
2. It will help if we change from 16-bit code units to 24-, 32- or 64-bit code units.

----------
components: Interpreter Core
messages: 403101
nosy: Mark.Shannon, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use sizeof(_Py_CODEUNIT) instead of literal 2 for the size of the code unit
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun Oct  3 15:45:55 2021
From: report at bugs.python.org (Randolf Scholz)
Date: Sun, 03 Oct 2021 19:45:55 +0000
Subject: [New-bugs-announce] [issue45356] Calling `help` executes
 @classmethod @property decorated methods
Message-ID: <1633290355.98.0.210301350099.issue45356@roundup.psfhosted.org>


New submission from Randolf Scholz <randolf.scholz at gmail.com>:

I noticed some strange behaviour when calling `help` on a class inheriting from a class or having itself @classmethod @property decorated methods.

```python
from time import sleep
from abc import ABC, ABCMeta, abstractmethod

class MyMetaClass(ABCMeta):
    @classmethod
    @property
    def expensive_metaclass_property(cls):
        """This may take a while to compute!"""
        print("computing metaclass property"); sleep(3)
        return "Phew, that was a lot of work!"

    
class MyBaseClass(ABC, metaclass=MyMetaClass):
    @classmethod
    @property
    def expensive_class_property(cls):
        """This may take a while to compute!"""
        print("computing class property .."); sleep(3)
        return "Phew, that was a lot of work!"
    
    @property
    def expensive_instance_property(self):
        """This may take a while to compute!"""
        print("computing instance property ..."); sleep(3)
        return "Phew, that was a lot of work!"

class MyClass(MyBaseClass):
    """Some subclass of MyBaseClass"""
    
help(MyClass)
```

Calling `help(MyClass)` will cause `expensive_class_property` to be executed 4 times (!)

The other two properties, `expensive_instance_property` and `expensive_metaclass_property` are not executed.

Secondly, only `expensive_instance_property` is listed as a read-only property; `expensive_class_property` is listed as a classmethod and `expensive_metaclass_property` is unlisted.

The problem is also present in '3.10.0rc2 (default, Sep 28 2021, 17:57:14) [GCC 10.2.1 20210110]'

Stack Overflow thread: https://stackoverflow.com/questions/69426309

----------
files: classmethod_property.py
messages: 403109
nosy: randolf.scholz
priority: normal
severity: normal
status: open
title: Calling `help` executes @classmethod @property decorated methods
type: behavior
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50325/classmethod_property.py

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

From report at bugs.python.org  Sun Oct  3 17:42:22 2021
From: report at bugs.python.org (CoolCat467)
Date: Sun, 03 Oct 2021 21:42:22 +0000
Subject: [New-bugs-announce] [issue45357] Idle does not check user config
 for extention configuration
Message-ID: <1633297342.93.0.20149347886.issue45357@roundup.psfhosted.org>


New submission from CoolCat467 <davenport.samuel09 at gmail.com>:

I was trying to write an extension for Idle, and was noticing extension keys defined in ~/.idlerc weren't being used, so I looked into it and found that in idlelib.config.idleConf, `GetExtensionKeys`, `__GetRawExtensionKeys`, and `GetKeyBinding` would never check for user keys, always assuming default keys have everything. This is not always true. In a system with multiple users, you would not want to modify the default config file for a custom extension, as that is used for everyone.

----------
assignee: terry.reedy
components: IDLE
messages: 403112
nosy: CoolCat467, terry.reedy
priority: normal
severity: normal
status: open
title: Idle does not check user config for extention configuration
type: behavior

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

From report at bugs.python.org  Sun Oct  3 18:03:46 2021
From: report at bugs.python.org (greob)
Date: Sun, 03 Oct 2021 22:03:46 +0000
Subject: [New-bugs-announce] [issue45358] Bogus cookie generated after
 invalid cookie attribute is input
Message-ID: <1633298626.44.0.0775080772803.issue45358@roundup.psfhosted.org>


New submission from greob <greob at yahoo.com.sg>:

Youtube sends cookies with some non-standard attributes. For example:
```
Secure-1PSID=XXXXXX; Domain=.youtube.com; Path=/; Expires=Tue, 03-Oct-2023 16:26:27 GMT; Secure; HttpOnly; Priority=HIGH; SameParty
```
Notice the Priority and SameParty attributes. 


In the case above, the cookie is entirely discarded because of the unexpected SameParty attribute. I have not read the specifications, but I would prefer to keep the cookie instead of discarding it. 
These unusual attributes are clearly used by Chromium. Firefox ignore these attributes and does not discard the cookies.

In another case, the "Priority" key/value attribute is present, which may or may not be followed by any other (valid) attributes. 
An extra cookie is then generated by http.cookies.BaseCookie.__parse_string() (cpython/Lib/http/cookies.py:539):

```
Set-Cookie: priority=high; Domain=www.youtube.com; Path=/; SameSite=none
```
There may even be duplicate cookies generated if the case changes (ie. "Priority=HIGH" would be yet another bogus cookie).

The reason for this is as follows:
The "priority=high" is seen as a key/value pair, and added to the parsed_items list with type TYPE_KEYVALUE, which is now the _second_ TYPE_KEYVALUE in the list. To my understanding, there should be only _one_ TYPE_KEYVALUE in this list, that is the actual cookie key/value pair. Any other item added to that list should be a TYPE_ATTRIBUTE.

In the for loop below (cpython/Lib/http/cookies.py:590), a new Morsel is created with key=Priority and value=HIGH, which is not what we want at all.

I have been working on a patch, but I keep pulling my hair over the fact that multiple key=value pairs can be found in the same string, which is expected by the test suite to result in multiple separate cookies.

An easy workaround would be to justadd "priority" to _reserved keys, and "sameparty" to known flags. Basically catching up with Google's "extensions".

Thoughts?

----------
components: Library (Lib)
messages: 403114
nosy: greob
priority: normal
severity: normal
status: open
title: Bogus cookie generated after invalid cookie attribute is input
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sun Oct  3 18:18:50 2021
From: report at bugs.python.org (Jacob Hayes)
Date: Sun, 03 Oct 2021 22:18:50 +0000
Subject: [New-bugs-announce] [issue45359] TopologicalSorter is not Generic
 at runtime (but is in typeshed)
Message-ID: <1633299530.43.0.181161136207.issue45359@roundup.psfhosted.org>


New submission from Jacob Hayes <jacob.r.hayes at gmail.com>:

Reproduction:

```
from graphlib import TopologicalSorter

TopologicalSorter[str]({"a": {}, "b": {"a"}})
```
```
$ mypy /tmp/toposort.py
Success: no issues found in 1 source file
$ python3 /tmp/toposort.py
Traceback (most recent call last):
  File "/tmp/toposort.py", line 3, in <module>
    TopologicalSorter[str]({"a": {}, "b": {"a"}})
TypeError: 'type' object is not subscriptable
```

I opened the issue here (rather than typeshed) because we'd presumably like to support this at runtime too.

Typeshed link: https://github.com/python/mypy/blob/0a830481980bfc554ded61a3eaaaecde384a21e4/mypy/typeshed/stdlib/graphlib.pyi#L6

----------
components: Library (Lib)
messages: 403115
nosy: JacobHayes
priority: normal
severity: normal
status: open
title: TopologicalSorter is not Generic at runtime (but is in typeshed)
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  4 02:07:10 2021
From: report at bugs.python.org (Terunobu Inaba)
Date: Mon, 04 Oct 2021 06:07:10 +0000
Subject: [New-bugs-announce] [issue45360] xml.etree.ElementTree: add feature
 in write to create directories also like mkdir -p
Message-ID: <1633327630.81.0.219409303004.issue45360@roundup.psfhosted.org>


New submission from Terunobu Inaba <incredibleteru at gmail.com>:

In the xml.etree.ElementTree module, the function "write(args)" (https://docs.python.org/ja/3/library/xml.etree.elementtree.html) does not seem to have a function like "-p" in "mkdir -p" in UNIX system, i.e., it will raise an error when some directories in the path argument do not exist in your PC.

I find this a bit uncomfortable. So, I would like to extend this function to be able to create directories only if they does not already exist.

----------
components: Library (Lib)
messages: 403120
nosy: i11u
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree: add feature in write to create directories also like mkdir -p
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  4 02:42:56 2021
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 04 Oct 2021 06:42:56 +0000
Subject: [New-bugs-announce] [issue45361] Provide a more convenient way to
 set an exception as "active", from Python code
Message-ID: <1633329776.11.0.630918001556.issue45361@roundup.psfhosted.org>


New submission from Nathaniel Smith <njs at pobox.com>:

Inside 'except' and 'finally' blocks, the interpreter keeps track of the 'active exception in the thread-state. It can be introspected via `sys.exc_info()`, it enables bare `raise`, and it triggers implicit context propagation.

In an odd bit of synchronicity, I recently bumped into two completely separate cases where Python code would benefit from being able to control this state directly:

- in the flat exception groups discussion [1], I noted that it would be useful if concurrency libraries could propagate this state into child tasks

- in bpo-27089, regarding some gnarly code in contextlib.ExitStack that simulates a set of nested try/finally blocks by running callback with the wrong exception context, and then introspecting the result and trying to fix it up after the fact. It turns out this code is difficult to understand and subtly buggy -- the PR at gh-27089 fixes one of the bugs here, but there are others [2]. It would be much simpler if it could just set the correct `exc_info` before calling each cleanup function, and then no fixups would be needed things would be set up correctly in the first place.

[1] https://discuss.python.org/t/flat-exception-groups-alternative-to-pep-654/10433

[2] https://github.com/python/cpython/pull/27089#issuecomment-932892687

But, currently, the *only* way to make an exception 'active' like this is to raise it and then catch it again. And this has some significant limitations:

- It unconditionally mutates the exception -- in particular both __context__ and __traceback__ are modified

- The "active exception" has type Optional[BaseException], since try/raise/except is block syntax, and you can't `raise None`. So if you want to propagate an arbitrary `sys.exc_info()` into a child task or into a simulated `finally` block, then you need two separate code paths depending on whether `sys.exc_info()[1]` is None or not.

- technically I think you can work around both of these issues with enough effort... but since try/raise/except is block syntax, the workarounds can't be hidden inside a function; you have to inline them into each usage site.

So... I'm thinking maybe we should have some stupid-simple, sharp-edged API to set `sys.exc_info()` from Python. Like, idk, `sys.set_exc_info(...)`, as a trivial wrapper around `PyErr_Restore`.

My main uncertainty is that I know the code for handling the exception state is quite complex, between the "exception stack", the tricky optimizations around partially-initialized exc_info tuples, pushing/popping the exc state in ceval.c, the tricks generators/coroutines use to save/restore exc_info across yields, etc. There might be some hidden dragons in here that require careful handling, and maybe it'll turn out we need to push/pop an exception instead of just setting it, or something like that.

But does the core idea make sense? Anyone aware of any dragons off the top of your head?

----------
messages: 403121
nosy: Mark.Shannon, gvanrossum, iritkatriel, ncoghlan, njs, yselivanov
priority: normal
severity: normal
status: open
title: Provide a more convenient way to set an exception as "active", from Python code
type: enhancement

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

From report at bugs.python.org  Mon Oct  4 05:56:52 2021
From: report at bugs.python.org (Martmists)
Date: Mon, 04 Oct 2021 09:56:52 +0000
Subject: [New-bugs-announce] [issue45362] dis does not work with the new
 optimized ops
Message-ID: <1633341412.48.0.798356810047.issue45362@roundup.psfhosted.org>


New submission from Martmists <martmists at gmail.com>:

Python 3.11.0a0 (heads/main:e6d1aa1, Oct  4 2021, 10:33:36) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> c = bytes([127, 1, 0, 2])  # LOAD_FAST__LOAD_FAST (1, 2)
>>> dis.dis(c)
          0 <127>                    1
          2 <0>
>>> c = bytes([48, 0, 161, 0])  # LOAD_GLOBAL_BUILTIN (0) CALL_FUNCTION (0)
>>> dis.dis(c)
          0 <48>
          2 CALL_METHOD              0

---

The reason for this seems to be the lack of definition in `opcode.py` aside from being mentioned in _specialized_instructions. Additionally, it seems dis._unpack_opargs is not yet prepared to support opcodes like LOAD_FAST__LOAD_FAST which take two arguments.

While I don't expect this to be a first priority in this big change, it's important to not forget it.

----------
components: Library (Lib)
messages: 403126
nosy: martmists
priority: normal
severity: normal
status: open
title: dis does not work with the new optimized ops
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct  4 07:11:07 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Oct 2021 11:11:07 +0000
Subject: [New-bugs-announce] [issue45363] Use instruction offsets in
 co_lnotab
Message-ID: <1633345867.06.0.564667934457.issue45363@roundup.psfhosted.org>


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

It was a part of the original patch for issue27129.

As well as in jumping instructions we can use instruction offsets instead of bytes offset in co_lnotab. It increases the range of offsets which can be encoded with a single byte, and therefore reduce the size of co_lnotab and its decoding time. It will allow to simplify the code if we use instruction offsets everywhere.

----------
components: Interpreter Core
messages: 403130
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use instruction offsets in co_lnotab
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct  4 10:51:53 2021
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Oct 2021 14:51:53 +0000
Subject: [New-bugs-announce] [issue45364] Add more documentation for
 ModuleSpec.loader_state.
Message-ID: <1633359113.08.0.945752109224.issue45364@roundup.psfhosted.org>


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

Currently ModuleSpec.loader_state is documented briefly once in the importlib docs. [1]  It should have more explanation, e.g. about when/why it should be used.  It should also be mentioned meaningfully in the MetapathFinder [2] and Loader [3] docs, as well as in the language reference [4].

Also see https://github.com/python/cpython/pull/28633#discussion_r720865971.

Note that ModuleSpec (and loader_state) were added in 3.4, so this documentation-only change would be helpful all the way back.  At the least we should update the docs back to 3.9, the current bug-fix release.


[1] https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.loader_state
[2] https://docs.python.org/3/library/importlib.html#importlib.abc.MetaPathFinder
[3] https://docs.python.org/3/library/importlib.html#importlib.abc.Loader
[4] https://docs.python.org/3/reference/import.html#loaders or https://docs.python.org/3/reference/import.html#module-spec

----------
assignee: docs at python
components: Documentation
messages: 403141
nosy: barry, brett.cannon, docs at python, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add more documentation for ModuleSpec.loader_state.
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Oct  4 15:31:22 2021
From: report at bugs.python.org (Xavier Morel)
Date: Mon, 04 Oct 2021 19:31:22 +0000
Subject: [New-bugs-announce] [issue45365] concurrent.futures.Future should
 be suitable for use outside of executors
Message-ID: <1633375882.11.0.38644719586.issue45365@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

concurrent.futures.Future currently has the note:

> Future instances are created by Executor.submit() and should not be created directly except for testing.

That seems like a shame as futures are useful concurrency construct and having to rebuild them "by hand" seems like a waste.

What are the issues which prevent safely using futures outside of executors, and is there a way they could be fixed / lifted?

----------
components: Library (Lib)
messages: 403181
nosy: xmorel
priority: normal
severity: normal
status: open
title: concurrent.futures.Future should be suitable for use outside of executors
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct  4 16:17:33 2021
From: report at bugs.python.org (simple_coder878)
Date: Mon, 04 Oct 2021 20:17:33 +0000
Subject: [New-bugs-announce] [issue45366] dataclass init=False field with
 default works but default_factory does not
Message-ID: <1633378653.41.0.620481624294.issue45366@roundup.psfhosted.org>


New submission from simple_coder878 <junk757 at gmail.com>:

Simple example
from dataclasses import dataclass, field

@dataclass(init=False)
class TestObject(object):
    m: str = field(default='hi')
    k: list = field(default_factory=list)

    def test(self):
        print(f'm is {self.m} ')
        print(f'k is {self.k}')

if __name__ == '__main__':
    myobject = TestObject()
    myobject.test()


Produces:

Traceback (most recent call last):
  File "H:\unit_test\tests_dataclass.py", line 81, in <module>
    myobject.test()
  File "H:\unit_test\tests_dataclass.py", line 76, in test
    print(f'k is {self.k}')
AttributeError: 'TestObject' object has no attribute 'k'
m is hi 

So m is initialized to hi but k just disappears

But wait there's more!

If i do 

from dataclasses import dataclass, field

@dataclass(init=False)
class TestObject(object):
    m: str = field(default='hi')
    k: list = field(default_factory=list)

    def test(self):
        print(f'm is {self.m} ')
        print(f'k is {self.k}')


@dataclass
class InheritedTestObject(TestObject):

    def __post_init__(self):
        super().__init__()
        print(f'Inherited m is {self.m} ')
        print(f'Inherited k is {self.k}')
        print(f'Inherited g is {self.k}')


if __name__ == '__main__':
    myobject = InheritedTestObject()
    myobject.test()

It produces:

Inherited m is hi 
Inherited k is []
Inherited g is []
m is hi 
k is []

Process finished with exit code 0

NO ERRORS!

It seems like a bug to me, but what is the expected behavior in this case? I would expect the first case to not error out and should have an empty list.

I've only tested this on Python 3.9 so far.

----------
components: ctypes
messages: 403182
nosy: simple_coder878
priority: normal
severity: normal
status: open
title: dataclass init=False field with default works but default_factory does not
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  4 23:44:12 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 05 Oct 2021 03:44:12 +0000
Subject: [New-bugs-announce] [issue45367] Specialize BINARY_MULTIPLY
Message-ID: <1633405452.94.0.0777171864008.issue45367@roundup.psfhosted.org>


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

I'm having trouble setting up a rigorous benchmark (Windows doesn't want to install greenlet for pyperformance), but just running a couple of individual files, I got this:

Mean +- std dev: [nbody_main] 208 ms +- 2 ms -> [nbody_specialized] 180 ms +- 2 ms: 1.16x faster
Benchmark hidden because not significant (1): pidigits
Mean +- std dev: [chaos_main] 127 ms +- 2 ms -> [chaos_specialized] 120 ms +- 1 ms: 1.06x faster
Mean +- std dev: [spectral_norm_main] 190 ms +- 10 ms -> [spectral_norm_specialized] 175 ms +- 1 ms: 1.09x faster
Mean +- std dev: [raytrace_main] 588 ms +- 48 ms -> [raytrace_specialized] 540 ms +- 4 ms: 1.09x faster

Hopefully those are accurate.

----------
components: Interpreter Core
messages: 403189
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Specialize BINARY_MULTIPLY
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct  5 00:26:55 2021
From: report at bugs.python.org (Narendra Madurkar)
Date: Tue, 05 Oct 2021 04:26:55 +0000
Subject: [New-bugs-announce] [issue45368] ~(True) and ~(False) gives
 incorrect result
Message-ID: <1633408015.49.0.720577239656.issue45368@roundup.psfhosted.org>


New submission from Narendra Madurkar <nmadurkar at gmail.com>:

~(True) returns -2
~(False) returns -1

----------
messages: 403190
nosy: nmadurkar
priority: normal
severity: normal
status: open
title: ~(True) and ~(False) gives incorrect result

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

From report at bugs.python.org  Tue Oct  5 00:56:22 2021
From: report at bugs.python.org (ramikg)
Date: Tue, 05 Oct 2021 04:56:22 +0000
Subject: [New-bugs-announce] [issue45369] Remove LibreSSL support
Message-ID: <1633409782.22.0.215867949251.issue45369@roundup.psfhosted.org>


New submission from ramikg <ramikgold at gmail.com>:

Python 3.10 drops support for LibreSSL (as per PEP 644), but there are still a few workarounds & mentions of LibreSSL in the source code.

The related PR cleans the code of any LibreSSL workarounds or mentions.

----------
assignee: christian.heimes
components: SSL
messages: 403193
nosy: christian.heimes, ramikg
priority: normal
severity: normal
status: open
title: Remove LibreSSL support
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct  5 04:10:47 2021
From: report at bugs.python.org (AdrienGoncalves)
Date: Tue, 05 Oct 2021 08:10:47 +0000
Subject: [New-bugs-announce] [issue45370] Typo in pep-0636 page
Message-ID: <1633421447.57.0.976232598926.issue45370@roundup.psfhosted.org>


New submission from AdrienGoncalves <goncalves.adrien at gmail.com>:

There is a typo in https://www.python.org/dev/peps/pep-0636/#composing-patterns

The second sentence in the first paragraph : "[...] we have being doing that implicitly in the examples above."

When it should be "[...] we have been doing that implicitly in the examples above."

----------
assignee: docs at python
components: Documentation
messages: 403201
nosy: adrigs, docs at python
priority: normal
severity: normal
status: open
title: Typo in pep-0636 page
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct  5 05:00:35 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Oct 2021 09:00:35 +0000
Subject: [New-bugs-announce] [issue45371] distutil's runtime_library_dir
 (rpath) option doesn't work with clang
Message-ID: <1633424435.3.0.953181779215.issue45371@roundup.psfhosted.org>


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

Chris Hills reported in bpo-43466 that the new --with-openssl-rpath=auto does not work with clang. It turns out to be a bug in distutils. UnixCCompiler.runtime_library_dir_option() does not detect clang correctly and emits wrong option for rpath.

----------
components: Distutils
messages: 403204
nosy: christian.heimes, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutil's runtime_library_dir (rpath) option doesn't work with clang
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Oct  5 05:17:20 2021
From: report at bugs.python.org (Aivar Annamaa)
Date: Tue, 05 Oct 2021 09:17:20 +0000
Subject: [New-bugs-announce] [issue45372] Unwarranted "certificate has
 expired" when urlopen-ing R3 sites
Message-ID: <1633425440.6.0.270287663773.issue45372@roundup.psfhosted.org>


New submission from Aivar Annamaa <aivar.annamaa at gmail.com>:

In one of my Windows 10 computers I'm not able to urlopen sites which use R3 certificates. The same is reported by several of the users of my software.

Following is taken from a session in the fresh IDLE 3.10 in up-to date Windows 10:


Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 18:46:30) [MSC v.1929 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> from urllib.request import urlopen
>>> urlopen("https://openssl.org")
Traceback (most recent call last):
  File "C:\Python310-32\lib\urllib\request.py", line 1348, in do_open
    h.request(req.get_method(), req.selector, req.data, headers,
  File "C:\Python310-32\lib\http\client.py", line 1276, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "C:\Python310-32\lib\http\client.py", line 1322, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "C:\Python310-32\lib\http\client.py", line 1271, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "C:\Python310-32\lib\http\client.py", line 1031, in _send_output
    self.send(msg)
  File "C:\Python310-32\lib\http\client.py", line 969, in send
    self.connect()
  File "C:\Python310-32\lib\http\client.py", line 1448, in connect
    self.sock = self._context.wrap_socket(self.sock,
  File "C:\Python310-32\lib\ssl.py", line 512, in wrap_socket
    return self.sslsocket_class._create(
  File "C:\Python310-32\lib\ssl.py", line 1070, in _create
    self.do_handshake()
  File "C:\Python310-32\lib\ssl.py", line 1341, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:997)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    urlopen("https://openssl.org")
  File "C:\Python310-32\lib\urllib\request.py", line 216, in urlopen
    return opener.open(url, data, timeout)
  File "C:\Python310-32\lib\urllib\request.py", line 519, in open
    response = self._open(req, data)
  File "C:\Python310-32\lib\urllib\request.py", line 536, in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
  File "C:\Python310-32\lib\urllib\request.py", line 496, in _call_chain
    result = func(*args)
  File "C:\Python310-32\lib\urllib\request.py", line 1391, in https_open
    return self.do_open(http.client.HTTPSConnection, req,
  File "C:\Python310-32\lib\urllib\request.py", line 1351, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:997)>



In the same session, requests works fine:

>>> import requests
>>> requests.get("https://openssl.org")
<Response [200]>



It's really weird, that in my another Windows 10, also 64-bit, having same state of updates, using same version of Python 3.10, connected to the same network -- everything works fine. Neither of the computers use any extra network middleware or proxies.

In both computers Chrome and Firefox are happy with the certificate of https://openssl.org

Same applies to Python 3.7

It must be somehow related to https://www.fortinet.com/blog/psirt-blogs/fortinet-and-expiring-lets-encrypt-certificates

----------
messages: 403208
nosy: aivarannamaa
priority: normal
severity: normal
status: open
title: Unwarranted "certificate has expired" when urlopen-ing R3 sites
versions: Python 3.10, Python 3.7

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

From report at bugs.python.org  Tue Oct  5 05:32:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Oct 2021 09:32:25 +0000
Subject: [New-bugs-announce] [issue45373] ./configure --enable-optimizations
 should enable LTO
Message-ID: <1633426345.9.0.0201314807782.issue45373@roundup.psfhosted.org>


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

When Python is configured with:

   ./configure --enable-optimizations

PGO is enabled but not LTO.

I recall that a few years ago, GCC with LTO had bugs. But now, GCC with LTO is reliable. I suggest to enable it by default in Python 3.11.

Or did I miss a reason to not do that?

----------
components: Build
messages: 403209
nosy: vstinner
priority: normal
severity: normal
status: open
title: ./configure --enable-optimizations should enable LTO
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct  5 05:47:10 2021
From: report at bugs.python.org (Chris Hills)
Date: Tue, 05 Oct 2021 09:47:10 +0000
Subject: [New-bugs-announce] [issue45374] sqlite3: Add configure option to
 set or auto-detect rpath to sqlite3 libs
Message-ID: <1633427230.04.0.331465850003.issue45374@roundup.psfhosted.org>


New submission from Chris Hills <chaz at chaz6.com>:

Similar to https://bugs.python.org/issue43466 for openssl, please add a configure option to set rpath for sqlite3.

--with-sqlite-rpath=<DIR|auto|no>

Ideally, when any dpeendency is discovered with pkg-config, the correct rpath should be set, but this would be a breaking change.

----------
assignee: docs at python
components: Documentation, Installation
messages: 403214
nosy: chaz6, docs at python
priority: normal
severity: normal
status: open
title: sqlite3: Add configure option to set or auto-detect rpath to sqlite3 libs
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct  5 07:38:41 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 05 Oct 2021 11:38:41 +0000
Subject: [New-bugs-announce] [issue45375] Windows assertion in out-of-tree
 debug build
Message-ID: <1633433921.42.0.136161828718.issue45375@roundup.psfhosted.org>


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

As seen in the release build for 3.11a1, an assertion is raised when attempting to launch the debug build out of tree.

       _RegenTestFrozenmain:
         Regenerate test_frozenmain.h
         D:\a\1\b\bin\amd64\python_d.exe Programs\freeze_test_frozenmain.py Programs/test_frozenmain.h
         Assertion failed: stdlibdir[wcslen(prefix)] == SEP, file D:\a\1\s\PC\getpathp.c, line 300

This causes the release to fail.

----------
assignee: steve.dower
components: Windows
messages: 403229
nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Windows assertion in out-of-tree debug build
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct  5 08:09:54 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 05 Oct 2021 12:09:54 +0000
Subject: [New-bugs-announce] [issue45376] Run Windows release docs build on
 regular CI
Message-ID: <1633435794.37.0.111310196296.issue45376@roundup.psfhosted.org>


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

Currently the release build of the CHM file runs on my dedicated build machine, which means there's no way to do a test run without starting the machine (normally clearing the code signing and PGO properties allows a build without needing it).

Originally the issue was that the docs build was taking >10minutes on CI, but not on my machine, which is why I moved it.

Should try moving it back, or at least enabling a skip option for it so that test runs can be done purely on free CI, rather than needing my account.

----------
assignee: steve.dower
components: Windows
messages: 403232
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Run Windows release docs build on regular CI

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

From report at bugs.python.org  Tue Oct  5 08:35:05 2021
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Tue, 05 Oct 2021 12:35:05 +0000
Subject: [New-bugs-announce] [issue45377] Default python 3 docs still
 pointing to 3.9.7
Message-ID: <1633437305.72.0.650229498176.issue45377@roundup.psfhosted.org>


New submission from Ra?l Cumplido <raulcumplido at gmail.com>:

We are going to start the python 3.10 work on the python-docs-es and we have realised that when accessing: https://docs.python.org/3/
It is still redirecting to Python 3.9.7 documentation

As Python 3.10 was released yesterday shouldn't the default docs point to python 3.10 already?

----------
assignee: docs at python
components: Documentation
messages: 403235
nosy: docs at python, mdk, raulcd
priority: normal
severity: normal
status: open
title: Default python 3 docs still pointing to 3.9.7
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct  5 11:51:22 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Oct 2021 15:51:22 +0000
Subject: [New-bugs-announce] [issue45378] Can't find "map" with search on
 docs.python.org
Message-ID: <1633449082.64.0.24886590221.issue45378@roundup.psfhosted.org>


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

I was looking for the docs for 'map' and tried to use the search box on docs.python.org. This gave a lot of things whose name started with or contained 'map', but the entry for the builtin map() function was hidden really far down under the heading "Builtin Functions" (https://docs.python.org/3.10/library/functions.html?highlight=map) rather than deep-linking to the entry I was looking for (https://docs.python.org/3.10/library/functions.html#map).

I'm sure that some tweak to the index builder could fix this, in general, for all builtin functions and types (many of which I imagine suffer from the effect -- having a short name that is used a lot as a part of other names).

----------
assignee: docs at python
components: Documentation
messages: 403245
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Can't find "map" with search on docs.python.org
type: behavior

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

From report at bugs.python.org  Tue Oct  5 11:52:00 2021
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Oct 2021 15:52:00 +0000
Subject: [New-bugs-announce] [issue45379] Improve errors related to frozen
 modules.
Message-ID: <1633449120.03.0.98563217148.issue45379@roundup.psfhosted.org>


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

In Python/import.c there are various situations in which an error state related to frozen modules might result and even lead to an exception.  In gh-28633 we consolidated these cases into a new "frozen_status" enum and added "set_frozen_error()" to set a consistent exception based on a status.

There are several deficiencies to address at this point:

* the conditions for the statuses are unclear [1][2]
* the error messages could be more helpful [3]
* maybe use a different error message for FROZEN_BAD_NAME (and perhaps FROZEN_DISABLED), rather than combining with FROZEN_NOT_FOUND 


[1] https://github.com/python/cpython/pull/28633#discussion_r720503665
[2] https://github.com/python/cpython/pull/28633#discussion_r720504275
[3] https://github.com/python/cpython/pull/28633#discussion_r720987412

----------
components: Interpreter Core
messages: 403246
nosy: barry, brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve errors related to frozen modules.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct  5 14:29:03 2021
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 05 Oct 2021 18:29:03 +0000
Subject: [New-bugs-announce] [issue45380] help() appears confused about the
 module of typing.Annotated
Message-ID: <1633458543.21.0.19270161871.issue45380@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

`help()` appears confused about the module of `typing.Annotated`. If you call `help()` on a parameterised "instance" of `typing.Annotated`, it will claim that `Annotated` belongs to whatever module the annotated type is from. Additionally, `help()` appears not to know about the `__metadata__` attribute of `typing.Annotated`.

```
>>> from typing import Annotated, Callable
>>> t = Annotated[int | str, "Some metadata"]
>>> help(t)
Help on _AnnotatedAlias in module types:

Annotated = int | str
>>> u = Annotated[Callable[[int], str], "Some metadata"]
>>> help(u)
Help on _AnnotatedAlias in module typing:

Annotated = typing.Callable[[int], str]
>>> s = Annotated[int, "Some metadata"]
Help on _AnnotatedAlias in module builtins:

Annotated = class int(object)
 |  int([x]) -> integer
 |  int(x, base=10) -> integer

# (etc., giving the entire output of help() for `int`)
```

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 403258
nosy: AlexWaygood, docs at python
priority: normal
severity: normal
status: open
title: help() appears confused about the module of typing.Annotated
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Oct  5 15:11:17 2021
From: report at bugs.python.org (A A)
Date: Tue, 05 Oct 2021 19:11:17 +0000
Subject: [New-bugs-announce] [issue45381] IDLE cannot kill process.
 "interupt" ctl+c and "restart shell" freeze program.
Message-ID: <1633461077.55.0.535298106793.issue45381@roundup.psfhosted.org>


New submission from A A <capsicumw at gmail.com>:

Idle3 with python 3.7.3 on Debian Buster and XFCE.
Attempting to run the line 'print ("Hello World" * 8**8)' from either the Idle shell window or Idle editor will cause Idle to hang and one CPU core runs 100%.(allowed it to run for several minutes) 
ctl+c or menu Shell>interrupt execution simply pauses CPU processing but does not terminate the process nor is there an option to continue the process. Following this interrupt with use of menu Shell>Restart-shell causes Idle to fully freeze and then requires a system terminate signal to close Idle.
The same line of python used in Idle on another student's MS-Windows laptop required ctl-alt-del this was a fresh download with v3.9 as I recall.

When used used on the system Bash shell and python 3.7.3, the line operates without any trouble and finishes in 20seconds as: $ python3 -c 'print ( "Hello World " * 8**8)' 

Suggestion is that the ctl+c or the Interrupt menu option in Idle should terminate the running code rather than pause it.

----------
assignee: terry.reedy
components: IDLE
messages: 403259
nosy: capsicumw, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE cannot kill process. "interupt" ctl+c and "restart shell" freeze program.
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct  5 15:43:57 2021
From: report at bugs.python.org (Alex Zaslavskis)
Date: Tue, 05 Oct 2021 19:43:57 +0000
Subject: [New-bugs-announce] [issue45382] platform() is not able to detect
 windows 11
Message-ID: <1633463037.19.0.965519087659.issue45382@roundup.psfhosted.org>


New submission from Alex Zaslavskis <sahsariga111 at gmail.com>:

I am updated to windows 11 . Now I am trying to write script that will detect is user use windows 11 or windows 10 . 
I was using the simplest way as possible: 
import platform 
print(platform.platform())
The result I got is : Windows-10-10.0.22000-SP0
That is quite correct . The build version is correct ,but the windows version is still not .

----------
components: Library (Lib)
messages: 403260
nosy: sahsariga111
priority: normal
severity: normal
status: open
title: platform() is not able to detect windows 11
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct  5 17:51:26 2021
From: report at bugs.python.org (Sebastian Berg)
Date: Tue, 05 Oct 2021 21:51:26 +0000
Subject: [New-bugs-announce] [issue45383] PyType_FromSpec API fails to use
 metaclass of bases
Message-ID: <1633470686.49.0.00898443232155.issue45383@roundup.psfhosted.org>


New submission from Sebastian Berg <sebastian at sipsolutions.net>:

The PyType_FromSpec fails to take care about MetaClasses.

     https://bugs.python.org/issue15870

Asks to create a new API to pass in the MetaClass.  This issue is only about "inheriting" the metaclass of the bases correctly.  Currently, Python fails to take into account that the bases may be MetaClass and not `PyType_Type` instances.

----------
components: C API, Interpreter Core
messages: 403273
nosy: petr.viktorin, seberg
priority: normal
pull_requests: 27093
severity: normal
status: open
title: PyType_FromSpec API fails to use metaclass of bases
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct  5 19:00:02 2021
From: report at bugs.python.org (Gregory Beauregard)
Date: Tue, 05 Oct 2021 23:00:02 +0000
Subject: [New-bugs-announce] [issue45384] Accept Final as indicating
 ClassVar for dataclass
Message-ID: <1633474802.74.0.28935369268.issue45384@roundup.psfhosted.org>


New submission from Gregory Beauregard <greg at greg.red>:

PEP 591 for the Final Attribute states "Type checkers should infer a final attribute that is initialized in a class body as being a class variable. Variables should not be annotated with both ClassVar and Final."

This is a bit of a typing conflict for dataclasses, where ClassVar is used to indicate a desired library behavior, but one may want to indicate Final.

I propose accepting the Final attribute as an indicator of a ClassVar in dataclasses class bodies in order to be better compatible with the Final PEP.

There is at least one edge case that would need to be handled where someone might want to explicitly mark a dataclass field Final, which could be allowed as a field:
a: Final[int] = dataclasses.field(init=False, default=10)

----------
components: Library (Lib)
messages: 403277
nosy: GBeauregard
priority: normal
severity: normal
status: open
title: Accept Final as indicating ClassVar for dataclass
type: enhancement

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

From report at bugs.python.org  Tue Oct  5 20:42:58 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 06 Oct 2021 00:42:58 +0000
Subject: [New-bugs-announce] [issue45385] Fix possible reference leak from
 descr_check
Message-ID: <1633480978.07.0.287145541934.issue45385@roundup.psfhosted.org>


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

Report from @kj: https://github.com/python/cpython/pull/28719#discussion_r721249643

----------
components: Interpreter Core
messages: 403282
nosy: corona10, kj, vstinner
priority: normal
severity: normal
status: open
title: Fix possible reference leak from descr_check
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Oct  6 02:53:27 2021
From: report at bugs.python.org (R)
Date: Wed, 06 Oct 2021 06:53:27 +0000
Subject: [New-bugs-announce] [issue45386] xmlrpc.client unimportable due to
 strfmt ValueError
Message-ID: <1633503207.0.0.80221316205.issue45386@roundup.psfhosted.org>


New submission from R <rtobarc at gmail.com>:

This is a problem caused by https://bugs.python.org/issue13305.

When running python in SerenityOS (https://serenityos.org/), the xmlrpc.client module fails to be imported. This is because the code that decides which format to use for getting 4-digit years, which issues a call to strfmt, raises a ValueError. The ValueError is raised because the second format that is tested yields no output with Serenity's strfmt implementation, so timemodule.strfmt returns NULL.

For reference, this is the code that fails:


_day0 = datetime(1, 1, 1)
if _day0.strftime('%Y') == '0001':      # Mac OS X
    def _iso8601_format(value):
        return value.strftime("%Y%m%dT%H:%M:%S")
elif _day0.strftime('%4Y') == '0001':   # Linux   <-- ValueError
    def _iso8601_format(value):
        return value.strftime("%4Y%m%dT%H:%M:%S")
else:
    def _iso8601_format(value):
        return value.strftime("%Y%m%dT%H:%M:%S").zfill(17)
del _day0

We have a local patch that improves on the current code, which I'll post as a PR now.

----------
components: Library (Lib)
messages: 403288
nosy: rtobar2
priority: normal
severity: normal
status: open
title: xmlrpc.client unimportable due to strfmt ValueError
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct  6 04:42:34 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Wed, 06 Oct 2021 08:42:34 +0000
Subject: [New-bugs-announce] [issue45387] GzipFile.write should be buffered
Message-ID: <1633509754.51.0.179214714383.issue45387@roundup.psfhosted.org>


New submission from Ruben Vorderman <r.h.p.vorderman at lumc.nl>:

Please consider the following code snippet:

    import gzip
    import sys

    with gzip.open(sys.argv[1], "rt") as in_file_h:
        with gzip.open(sys.argv[2], "wt", compresslevel=1) as out_file_h:
            for line in in_file_h:
                # Do processing on line here
                modified_line = line
                # End processing
                out_file_h.write(modified_line)

This is very slow, due to write being called for every line. This is the current implementation of write:
https://github.com/python/cpython/blob/c379bc5ec9012cf66424ef3d80612cf13ec51006/Lib/gzip.py#L272

It:
- Checks if the file is not closed
- Checks if the correct mode is set
- Checks if the file is not closed (again, but in a different way)
- Checks if the data is bytes, bytearray or something that supports the buffer protocol
- Gets the length
- Compresses the data
- updates the size and offset
- updates the checksum

Doing this for every line written is very costly and creates a lot of overhead in Python calls. We spent a lot of time in Python and a lot less in the fast C zlib code that does the actual compression.

This problem is already solved on the read side. A _GzipReader object is used for reading. This is put in an io.BufferedReader which is used as the underlying buffer for GzipFile.read. This way, lines  are read quite fast from a GzipFile without the checksum etc. being updated on every line read.

A similar solution should be written for write.
I volunteer (I have done some other work on gzip.py already), although I cannot give an ETA at this time.

----------
messages: 403289
nosy: rhpvorderman
priority: normal
severity: normal
status: open
title: GzipFile.write should be buffered

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

From report at bugs.python.org  Wed Oct  6 06:06:24 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 06 Oct 2021 10:06:24 +0000
Subject: [New-bugs-announce] [issue45388] Use JUMP_FORWARD for all forward
 jumps.
Message-ID: <1633514784.49.0.280393257711.issue45388@roundup.psfhosted.org>


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

Python has two unconditional jumps, JUMP_ABSOLUTE and JUMP_FORWARD.

The bytecode compiler should ensure that all forward jumps use JUMP_FORWARD and all backwards jumps use JUMP_ABSOLUTE.

That way, the interpreter will know that JUMP_ABSOLUTE jumps are backwards and won't need to check.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 403291
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Use JUMP_FORWARD for all forward jumps.
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct  6 07:26:20 2021
From: report at bugs.python.org (gaborjbernat)
Date: Wed, 06 Oct 2021 11:26:20 +0000
Subject: [New-bugs-announce] [issue45389]
 https://docs.python.org/3/objects.inv still points to 3.10
Message-ID: <1633519580.67.0.482188362776.issue45389@roundup.psfhosted.org>


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

https://docs.python.org/3/library/ links now to 3.10; however, the objects inventory does not.

? curl -s https://docs.python.org/3/objects.inv | head -n 3
# Sphinx inventory version 2
# Project: Python
# Version: 3.9

? curl -s https://docs.python.org/3.10/objects.inv | head -n 3
# Sphinx inventory version 2
# Project: Python
# Version: 3.10

----------
assignee: docs at python
components: Documentation
messages: 403293
nosy: docs at python, gaborjbernat
priority: normal
severity: normal
status: open
title: https://docs.python.org/3/objects.inv still points to 3.10
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct  6 07:30:42 2021
From: report at bugs.python.org (Marco Pagliaricci)
Date: Wed, 06 Oct 2021 11:30:42 +0000
Subject: [New-bugs-announce] [issue45390] asyncio.Task doesn't propagate
 CancelledError() exception correctly.
Message-ID: <1633519842.27.0.396754460358.issue45390@roundup.psfhosted.org>


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

I've spotted a little bug in how asyncio.CancelledError() exception is propagated inside an asyncio.Task.

Since python 3.9 the asyncio.Task.cancel() method has a new 'msg' parameter, that will create an asyncio.CancelledError(msg) exception incorporating that message.

The exception is successfully propagated to the coroutine the asyncio.Task is running, so the coroutine successfully gets raised an asyncio.CancelledError(msg) with the specified message in asyncio.Task.cancel(msg) method.

But, once the asyncio.Task is cancelled, is impossible to retrieve that original asyncio.CancelledError(msg) exception with the message, because it seems that *a new* asyncio.CancelledError() [without the message] is raised when asyncio.Task.result() or asyncio.Task.exception() methods are called.

I have the feeling that this is just wrong, and that the original message specified in asyncio.Task.cancel(msg) should be propagated even also asyncio.Task.result() is called.

I'm including a little snippet of code that clearly shows this bug.

I'm using python 3.9.6, in particular:
Python 3.9.6 (default, Aug 21 2021, 09:02:49) 
[GCC 10.2.1 20210110] on linux

----------
components: asyncio
files: task_bug.py
messages: 403294
nosy: asvetlov, pagliaricci.m, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Task doesn't propagate CancelledError() exception correctly.
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50328/task_bug.py

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

From report at bugs.python.org  Wed Oct  6 08:20:50 2021
From: report at bugs.python.org (gaborjbernat)
Date: Wed, 06 Oct 2021 12:20:50 +0000
Subject: [New-bugs-announce] [issue45391] 3.10 objects.inv classifies
 UnionType as data
Message-ID: <1633522850.1.0.516575372895.issue45391@roundup.psfhosted.org>


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

It's a class though:

? sphobjinv suggest ./objects.inv UnionType
:py:data:`types.UnionType`

defined as:

UnionType = type(int | str)

----------
assignee: docs at python
components: Documentation
messages: 403300
nosy: docs at python, gaborjbernat
priority: normal
severity: normal
status: open
title: 3.10 objects.inv classifies UnionType as data
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct  6 09:54:59 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Oct 2021 13:54:59 +0000
Subject: [New-bugs-announce] [issue45392] docstring of "type" could use an
 update
Message-ID: <1633528499.41.0.143485330537.issue45392@roundup.psfhosted.org>


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

The docstring of the "type" builtin is mildly confusing. Here's what the first few lines of the output for `help(type)` look like for me (on Python 3.10.0rc2):

class type(object)
 |  type(object_or_name, bases, dict)
 |  type(object) -> the object's type
 |  type(name, bases, dict) -> a new type

The first line there seems redundant, and potentially misleading, since it suggests that `type(object, bases, dict)` might be legal.

The third line is missing mention of possible keyword arguments.

----------
messages: 403302
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: docstring of "type" could use an update

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

From report at bugs.python.org  Wed Oct  6 11:33:48 2021
From: report at bugs.python.org (Max)
Date: Wed, 06 Oct 2021 15:33:48 +0000
Subject: [New-bugs-announce] [issue45393] help() on operator precedence has
 confusing entries "avait" "x" and "not" "x"
Message-ID: <1633534428.51.0.112977953361.issue45393@roundup.psfhosted.org>


New submission from Max <mh+bugs.python.org at dsi972.fr>:

Nobody seems to have noticed this AFAICS: 
If you type, e.g., help('+') to get help on operator precedence, the fist column gives a lit of operators for each row corresponding to a given precedence. However, the row for "not" (and similar for "await"), has the entry

"not" "x"

That looks as if there were two operators, "not" and "x". But the letter x is just an argument to the operator, so it should be:

 "not x"

exactly as for "+x" and "-x" and "~x" and "x[index]" and "x.attribute", where also x is not part of the operator but an argument.

On the corresponding web page https://docs.python.org/3/reference/expressions.html#operator-summary
it is displayed correctly, there are no quotes.

----------
assignee: docs at python
components: Documentation
messages: 403321
nosy: MFH, docs at python
priority: normal
severity: normal
status: open
title: help() on operator precedence has confusing entries "avait" "x" and "not" "x"
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/issue45393>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:28:04 2021
From: report at bugs.python.org (Joshua)
Date: Wed, 06 Oct 2021 17:28:04 +0000
Subject: [New-bugs-announce] [issue45394] pip install numpy not working in
 3.11.0a on macOS 11.6
Message-ID: <1633541284.23.0.881547184304.issue45394@roundup.psfhosted.org>


New submission from Joshua <joshua at himmens.com>:

pip3.11 install numpy failed on a fresh install of python 3.11.0a on macOS 11.6.



pip3.11 install numpy
Collecting numpy
  Downloading numpy-1.21.1.zip (10.3 MB)
     |????????????????????????????????| 10.3 MB 14.1 MB/s 
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: numpy
  Building wheel for numpy (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /Library/Frameworks/Python.framework/Versions/3.11/bin/python3.11 /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmpiixoj1ei
       cwd: /private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e
  Complete output (936 lines):
  setup.py:63: RuntimeWarning: NumPy 1.21.1 may not yet support Python 3.11.
    warnings.warn(
  Running from numpy source directory.
  /private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/tools/cythonize.py:69: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
    from distutils.version import LooseVersion
  Processing numpy/random/_bounded_integers.pxd.in
  Processing numpy/random/_philox.pyx
  Processing numpy/random/_bounded_integers.pyx.in
  Processing numpy/random/_sfc64.pyx
  Processing numpy/random/_mt19937.pyx
  Processing numpy/random/bit_generator.pyx
  Processing numpy/random/mtrand.pyx
  Processing numpy/random/_generator.pyx
  Processing numpy/random/_pcg64.pyx
  Processing numpy/random/_common.pyx
  Cythonizing sources
  blas_opt_info:
  blas_mkl_info:
  customize UnixCCompiler
    libraries mkl_rt not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
  blis_info:
    libraries blis not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
  openblas_info:
    libraries openblas not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
  accelerate_info:
    libraries accelerate not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
  Library accelerate was not found. Ignoring
    libraries veclib not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
  Library veclib was not found. Ignoring
    FOUND:
      extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
      extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
      define_macros = [('NO_ATLAS_INFO', 3), ('HAVE_CBLAS', None)]
  
    FOUND:
      extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
      extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
      define_macros = [('NO_ATLAS_INFO', 3), ('HAVE_CBLAS', None)]
  
  non-existing path in 'numpy/distutils': 'site.cfg'
  lapack_opt_info:
  lapack_mkl_info:
    libraries mkl_rt not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
  openblas_lapack_info:
    libraries openblas not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
  openblas_clapack_info:
    libraries openblas,lapack not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
  flame_info:
    libraries flame not found in ['/Library/Frameworks/Python.framework/Versions/3.11/lib', '/usr/local/lib', '/usr/lib']
    NOT AVAILABLE
  
    FOUND:
      extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
      extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
      define_macros = [('NO_ATLAS_INFO', 3), ('HAVE_CBLAS', None)]
  
  Warning: attempted relative import with no known parent package
  /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/distutils/dist.py:274: UserWarning: Unknown distribution option: 'define_macros'
    warnings.warn(msg)
  running bdist_wheel
  running build
  running config_cc
  unifing config_cc, config, build_clib, build_ext, build commands --compiler options
  running config_fc
  unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options
  running build_src
  build_src
  building py_modules sources
  creating build
  creating build/src.macosx-10.9-universal2-3.11
  creating build/src.macosx-10.9-universal2-3.11/numpy
  creating build/src.macosx-10.9-universal2-3.11/numpy/distutils
  building library "npymath" sources
  Could not locate executable gfortran
  Could not locate executable f95
  Could not locate executable f90
  Could not locate executable f77
  Could not locate executable xlf90
  Could not locate executable xlf
  Could not locate executable ifort
  Could not locate executable ifc
  Could not locate executable g77
  Could not locate executable g95
  Could not locate executable pgfortran
  don't know how to compile Fortran code on platform 'posix'
  creating build/src.macosx-10.9-universal2-3.11/numpy/core
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath/npy_math_internal.h
    adding 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath' to include_dirs.
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath/ieee754.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath/npy_math_complex.c
  None - nothing done with h_files = ['build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath/npy_math_internal.h']
  building library "npyrandom" sources
  building extension "numpy.core._multiarray_tests" sources
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/_multiarray_tests.c
  building extension "numpy.core._multiarray_umath" sources
  non-existing path in 'numpy/core': 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/common'
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/arraytypes.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/einsum.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/einsum_sumprod.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/lowlevel_strided_loops.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/nditer_templ.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/scalartypes.c
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src/common
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_sort.h
    adding 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/common' to include_dirs.
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/quicksort.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/mergesort.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/timsort.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/heapsort.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/radixsort.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_partition.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/selection.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_binsearch.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/binsearch.c
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/funcs.inc
    adding 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath' to include_dirs.
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/simd.inc
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_utils.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_unary_fp.dispatch.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithm_fp.dispatch.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithmetic.dispatch.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_trigonometric.dispatch.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_exponent_log.dispatch.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/matmul.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/matmul.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/clip.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/clip.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/scalarmath.c
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/templ_common.h
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_cpu_features.c
  numpy.core - nothing done with h_files = ['build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_sort.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_partition.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_binsearch.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/funcs.inc', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/simd.inc', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_utils.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/matmul.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/clip.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/templ_common.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy/config.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy/_numpyconfig.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy/__multiarray_api.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy/__ufunc_api.h']
  building extension "numpy.core._umath_tests" sources
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/_umath_tests.c
  building extension "numpy.core._rational_tests" sources
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/_rational_tests.c
  building extension "numpy.core._struct_ufunc_tests" sources
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/_struct_ufunc_tests.c
  building extension "numpy.core._operand_flag_tests" sources
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/_operand_flag_tests.c
  building extension "numpy.core._simd" sources
  creating build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd/_simd_inc.h
    adding 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd' to include_dirs.
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd/_simd_data.inc
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd/_simd.dispatch.c
  numpy.core - nothing done with h_files = ['build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd/_simd_inc.h', 'build/src.macosx-10.9-universal2-3.11/numpy/core/src/_simd/_simd_data.inc']
  building extension "numpy.fft._pocketfft_internal" sources
  building extension "numpy.linalg.lapack_lite" sources
  creating build/src.macosx-10.9-universal2-3.11/numpy/linalg
  building extension "numpy.linalg._umath_linalg" sources
  conv_template:> build/src.macosx-10.9-universal2-3.11/numpy/linalg/umath_linalg.c
  building extension "numpy.random._mt19937" sources
  building extension "numpy.random._philox" sources
  building extension "numpy.random._pcg64" sources
  building extension "numpy.random._sfc64" sources
  building extension "numpy.random._common" sources
  building extension "numpy.random.bit_generator" sources
  building extension "numpy.random._generator" sources
  building extension "numpy.random._bounded_integers" sources
  building extension "numpy.random.mtrand" sources
  building data_files sources
  build_src: building npy-pkg config files
  running build_py
  creating build/lib.macosx-10.9-universal2-3.11
  creating build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/conftest.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/version.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/_version.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/_globals.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/dual.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/_distributor_init.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/ctypeslib.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/matlib.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying numpy/_pytesttester.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  copying build/src.macosx-10.9-universal2-3.11/numpy/__config__.py -> build/lib.macosx-10.9-universal2-3.11/numpy
  creating build/lib.macosx-10.9-universal2-3.11/numpy/compat
  copying numpy/compat/py3k.py -> build/lib.macosx-10.9-universal2-3.11/numpy/compat
  copying numpy/compat/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/compat
  copying numpy/compat/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/compat
  copying numpy/compat/_inspect.py -> build/lib.macosx-10.9-universal2-3.11/numpy/compat
  creating build/lib.macosx-10.9-universal2-3.11/numpy/compat/tests
  copying numpy/compat/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/compat/tests
  copying numpy/compat/tests/test_compat.py -> build/lib.macosx-10.9-universal2-3.11/numpy/compat/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/umath.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/fromnumeric.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_dtype.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_add_newdocs.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_methods.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_internal.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_string_helpers.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/multiarray.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_asarray.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/records.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_add_newdocs_scalars.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/setup_common.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/memmap.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/overrides.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/getlimits.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_dtype_ctypes.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/defchararray.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/shape_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/machar.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/numeric.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/function_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/einsumfunc.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/umath_tests.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_ufunc_config.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_exceptions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/numerictypes.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/_type_aliases.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/cversions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/arrayprint.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  copying numpy/core/code_generators/generate_numpy_api.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core
  creating build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_numerictypes.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_scalar_methods.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_scalarmath.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_item_selection.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_array_coercion.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_machar.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_unicode.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_cpu_dispatcher.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_arrayprint.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_scalarbuffer.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_indexerrors.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_print.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_half.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_arraymethod.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_mem_overlap.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_shape_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_deprecations.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_errstate.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_records.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_simd.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_scalarinherit.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_indexing.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_umath.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_numeric.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_function_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_datetime.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test__exceptions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_extint128.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_cython.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_umath_complex.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/_locales.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_defchararray.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_conversion_utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_scalarprint.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_casting_unittests.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_abc.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_ufunc.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_dtype.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_umath_accuracy.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_simd_module.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_getlimits.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_einsum.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_api.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_longdouble.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_overrides.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_scalar_ctors.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_multiarray.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_memmap.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_nditer.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_cpu_features.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_protocols.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_argparse.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  copying numpy/core/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/core/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/unixccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/numpy_distribution.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/conv_template.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/cpuinfo.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/ccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/msvc9compiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/npy_pkg_config.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/misc_util.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/log.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/line_endings.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/lib2def.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/pathccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/system_info.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/core.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/exec_command.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/from_template.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/mingw32ccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/extension.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/msvccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/intelccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/_shell_utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying numpy/distutils/ccompiler_opt.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  copying build/src.macosx-10.9-universal2-3.11/numpy/distutils/__config__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils
  creating build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/build.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/config_compiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/build_ext.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/config.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/install_headers.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/build_py.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/build_src.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/sdist.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/build_scripts.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/bdist_rpm.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/install_clib.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/build_clib.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/autodist.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/egg_info.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/install.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/develop.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  copying numpy/distutils/command/install_data.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/command
  creating build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/gnu.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/compaq.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/intel.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/none.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/nag.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/pg.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/ibm.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/sun.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/nv.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/lahey.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/g95.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/mips.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/hpux.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/environment.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/pathf95.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/fujitsu.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/absoft.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  copying numpy/distutils/fcompiler/vast.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/fcompiler
  creating build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_system_info.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_ccompiler_opt_conf.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_mingw32ccompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_from_template.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_fcompiler_intel.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_misc_util.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_fcompiler.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_build_ext.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_shell_utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_exec_command.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_npy_pkg_config.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_fcompiler_nagfor.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_ccompiler_opt.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  copying numpy/distutils/tests/test_fcompiler_gnu.py -> build/lib.macosx-10.9-universal2-3.11/numpy/distutils/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/doc
  copying numpy/doc/constants.py -> build/lib.macosx-10.9-universal2-3.11/numpy/doc
  copying numpy/doc/ufuncs.py -> build/lib.macosx-10.9-universal2-3.11/numpy/doc
  copying numpy/doc/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/doc
  creating build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/cfuncs.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/common_rules.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/crackfortran.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/cb_rules.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/rules.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/f2py2e.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/func2subr.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/__version__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/diagnose.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/capi_maps.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/f90mod_rules.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/f2py_testing.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/use_rules.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/auxfuncs.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  copying numpy/f2py/__main__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py
  creating build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_mixed.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_return_logical.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_assumed_shape.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_common.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_kind.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_array_from_pyobj.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_return_real.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/util.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_size.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_callback.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_string.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_module_doc.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_quoted_character.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_parameter.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_abstract_interface.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_semicolon_split.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_compile_function.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_block_docstring.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_return_integer.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_return_character.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_return_complex.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_crackfortran.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  copying numpy/f2py/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/f2py/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/fft
  copying numpy/fft/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft
  copying numpy/fft/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft
  copying numpy/fft/helper.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft
  copying numpy/fft/_pocketfft.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft
  creating build/lib.macosx-10.9-universal2-3.11/numpy/fft/tests
  copying numpy/fft/tests/test_pocketfft.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft/tests
  copying numpy/fft/tests/test_helper.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft/tests
  copying numpy/fft/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/fft/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/_iotools.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/mixins.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/nanfunctions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/recfunctions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/histograms.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/scimath.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/_version.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/user_array.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/format.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/twodim_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/index_tricks.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/npyio.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/shape_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/stride_tricks.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/arrayterator.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/function_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/arraysetops.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/arraypad.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/type_check.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/polynomial.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/_datasource.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  copying numpy/lib/ufunclike.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib
  creating build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_type_check.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_financial_expired.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_twodim_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_polynomial.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test__iotools.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_shape_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_ufunclike.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_index_tricks.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_arrayterator.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test__version.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_io.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_arraysetops.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_function_base.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_arraypad.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_mixins.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_packbits.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test__datasource.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_stride_tricks.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_recfunctions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_nanfunctions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_format.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_histograms.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  copying numpy/lib/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/lib/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/linalg
  copying numpy/linalg/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg
  copying numpy/linalg/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg
  copying numpy/linalg/linalg.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg
  creating build/lib.macosx-10.9-universal2-3.11/numpy/linalg/tests
  copying numpy/linalg/tests/test_linalg.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg/tests
  copying numpy/linalg/tests/test_deprecations.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg/tests
  copying numpy/linalg/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg/tests
  copying numpy/linalg/tests/test_build.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg/tests
  copying numpy/linalg/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/linalg/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/extras.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/testutils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/core.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/bench.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/timer_comparison.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  copying numpy/ma/mrecords.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma
  creating build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_old_ma.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_core.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_deprecations.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_subclassing.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_extras.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_mrecords.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  copying numpy/ma/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/ma/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib
  copying numpy/matrixlib/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib
  copying numpy/matrixlib/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib
  copying numpy/matrixlib/defmatrix.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib
  creating build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_matrix_linalg.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_defmatrix.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_interaction.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_numeric.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_masked_matrix.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_multiarray.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  copying numpy/matrixlib/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/matrixlib/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/laguerre.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/_polybase.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/polyutils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/hermite_e.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/chebyshev.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/polynomial.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/legendre.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  copying numpy/polynomial/hermite.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial
  creating build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_chebyshev.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_hermite_e.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_polynomial.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_laguerre.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_legendre.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_printing.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_hermite.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_classes.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  copying numpy/polynomial/tests/test_polyutils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/polynomial/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/random
  copying numpy/random/_pickle.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random
  copying numpy/random/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random
  copying numpy/random/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random
  creating build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_generator_mt19937.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_randomstate.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_direct.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_extending.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_smoke.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_randomstate_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_seed_sequence.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_generator_mt19937_regressions.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_random.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  copying numpy/random/tests/test_regression.py -> build/lib.macosx-10.9-universal2-3.11/numpy/random/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/testing
  copying numpy/testing/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing
  copying numpy/testing/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing
  copying numpy/testing/utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing
  copying numpy/testing/print_coercion_tables.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing
  creating build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  copying numpy/testing/_private/nosetester.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  copying numpy/testing/_private/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  copying numpy/testing/_private/noseclasses.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  copying numpy/testing/_private/utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  copying numpy/testing/_private/parameterized.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  copying numpy/testing/_private/decorators.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/_private
  creating build/lib.macosx-10.9-universal2-3.11/numpy/testing/tests
  copying numpy/testing/tests/test_utils.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/tests
  copying numpy/testing/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/tests
  copying numpy/testing/tests/test_doctesting.py -> build/lib.macosx-10.9-universal2-3.11/numpy/testing/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_char_codes.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_extended_precision.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_callable.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_generic_alias.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_nbit.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_dtype_like.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/mypy_plugin.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/setup.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_array_like.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_scalars.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_shape.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  copying numpy/typing/_add_docstring.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing
  creating build/lib.macosx-10.9-universal2-3.11/numpy/typing/tests
  copying numpy/typing/tests/test_isfile.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing/tests
  copying numpy/typing/tests/test_typing.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing/tests
  copying numpy/typing/tests/test_runtime.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing/tests
  copying numpy/typing/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing/tests
  copying numpy/typing/tests/test_generic_alias.py -> build/lib.macosx-10.9-universal2-3.11/numpy/typing/tests
  creating build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_warnings.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_matlib.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_ctypeslib.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_numpy_version.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/__init__.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_reloading.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_public_api.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  copying numpy/tests/test_scripts.py -> build/lib.macosx-10.9-universal2-3.11/numpy/tests
  UPDATING build/lib.macosx-10.9-universal2-3.11/numpy/_version.py
  set build/lib.macosx-10.9-universal2-3.11/numpy/_version.py to '1.21.1'
  running build_clib
  customize UnixCCompiler
  customize UnixCCompiler using new_build_clib
  CCompilerOpt.__init__[948] : unable to detect CPU architecture which lead to disable the optimization. check dist_info:<<
  ('macosx-10.9-universal2', 'clang', '-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g -ffp-exception-behavior=strict')
  >>
  CCompilerOpt.cc_test_flags[1008] : testing flags (-march=native)
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/numpy
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/numpy/distutils
  creating /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/numpy/distutils/checks
  compile options: '-Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  extra options: '-march=native'
  CCompilerOpt.dist_test[576] : CCompilerOpt._dist_test_spawn[711] : Command (clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c /private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/numpy/distutils/checks/test_flags.c -o /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/numpy/distutils/checks/test_flags.o -MMD -MF /var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/tmp9fkpontu/private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/numpy/distutils/checks/test_flags.o.d -march=native) failed with exit status 1 output ->
  clang: error: the clang compiler does not support '-march=native'
  
  CCompilerOpt.cc_test_flags[1012] : testing failed
  CCompilerOpt.cc_test_flags[1008] : testing flags (-O3)
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  compile options: '-Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  extra options: '-O3'
  CCompilerOpt.cc_test_flags[1008] : testing flags (-Werror)
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  compile options: '-Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  extra options: '-Werror'
  CCompilerOpt.__init__[1696] : check requested baseline
  CCompilerOpt.__init__[1705] : check requested dispatch-able features
  CCompilerOpt.__init__[1721] : initialize targets groups
  CCompilerOpt.__init__[1723] : parse target group simd_test
  CCompilerOpt._parse_target_tokens[1934] : skip targets (VSX2 FMA4 AVX512F NEON (FMA3 AVX2) SSE2 AVX512_SKX SSE42 VSX3 VSX XOP ASIMD) not part of baseline or dispatch-able features
  CCompilerOpt.generate_dispatch_header[2267] : generate CPU dispatch header: (build/src.macosx-10.9-universal2-3.11/numpy/distutils/include/npy_cpu_dispatch_config.h)
  CCompilerOpt.generate_dispatch_header[2276] : dispatch header dir build/src.macosx-10.9-universal2-3.11/numpy/distutils/include does not exist, creating it
  building 'npymath' library
  compiling C sources
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  creating build/temp.macosx-10.9-universal2-3.11
  creating build/temp.macosx-10.9-universal2-3.11/numpy
  creating build/temp.macosx-10.9-universal2-3.11/numpy/core
  creating build/temp.macosx-10.9-universal2-3.11/numpy/core/src
  creating build/temp.macosx-10.9-universal2-3.11/numpy/core/src/npymath
  creating build/temp.macosx-10.9-universal2-3.11/build
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath
  compile options: '-Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -Inumpy/core/include -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy -Ibuild/src.macosx-10.9-universal2-3.11/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  clang: numpy/core/src/npymath/npy_math.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath/npy_math_complex.c
  clang: numpy/core/src/npymath/halffloat.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath/ieee754.c
  xcrun: adding 4 object files to build/temp.macosx-10.9-universal2-3.11/libnpymath.a
  warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: build/temp.macosx-10.9-universal2-3.11/libnpymath.a will be fat and ar(1) will not be able to operate on it
  ranlib:@ build/temp.macosx-10.9-universal2-3.11/libnpymath.a
  building 'npyrandom' library
  compiling C sources
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  creating build/temp.macosx-10.9-universal2-3.11/numpy/random
  creating build/temp.macosx-10.9-universal2-3.11/numpy/random/src
  creating build/temp.macosx-10.9-universal2-3.11/numpy/random/src/distributions
  compile options: '-Inumpy/core/include -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy -Ibuild/src.macosx-10.9-universal2-3.11/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  clang: numpy/random/src/distributions/logfactorial.c
  clang: numpy/random/src/distributions/distributions.c
  clang: numpy/random/src/distributions/random_mvhg_count.c
  clang: numpy/random/src/distributions/random_mvhg_marginals.c
  clang: numpy/random/src/distributions/random_hypergeometric.c
  xcrun: adding 5 object files to build/temp.macosx-10.9-universal2-3.11/libnpyrandom.a
  warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: build/temp.macosx-10.9-universal2-3.11/libnpyrandom.a will be fat and ar(1) will not be able to operate on it
  ranlib:@ build/temp.macosx-10.9-universal2-3.11/libnpyrandom.a
  running build_ext
  customize UnixCCompiler
  customize UnixCCompiler using new_build_ext
  CCompilerOpt.__init__[781] : hit the memory cache
  CCompilerOpt.generate_dispatch_header[2267] : generate CPU dispatch header: (build/src.macosx-10.9-universal2-3.11/numpy/distutils/include/npy_cpu_dispatch_config.h)
  building 'numpy.core._multiarray_tests' extension
  compiling C sources
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray
  creating build/temp.macosx-10.9-universal2-3.11/numpy/core/src/common
  compile options: '-DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -Inumpy/core/include -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy -Ibuild/src.macosx-10.9-universal2-3.11/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/_multiarray_tests.c
  clang: numpy/core/src/common/mem_overlap.c
  clang: numpy/core/src/common/npy_argparse.c
  clang -bundle -undefined dynamic_lookup -arch arm64 -arch x86_64 -g build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/_multiarray_tests.o build/temp.macosx-10.9-universal2-3.11/numpy/core/src/common/mem_overlap.o build/temp.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_argparse.o -Lbuild/temp.macosx-10.9-universal2-3.11 -lnpymath -o build/lib.macosx-10.9-universal2-3.11/numpy/core/_multiarray_tests.cpython-311-darwin.so
  building 'numpy.core._multiarray_umath' extension
  compiling C dispatch-able sources
  CCompilerOpt.parse_targets[1763] : looking for '@targets' inside ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_unary_fp.dispatch.c
  CCompilerOpt._parse_target_tokens[1934] : skip targets (VSX2 SSE2 NEON) not part of baseline or dispatch-able features
  CCompilerOpt._parse_target_tokens[1958] : policy 'MAXOPT' is ON
  CCompilerOpt._parse_policy_maxopt[2067] : debug mode is detected, policy 'maxopt' is skipped.
  CCompilerOpt._generate_config[2501] : generate dispatched config ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_unary_fp.dispatch.h
  CCompilerOpt.parse_targets[1763] : looking for '@targets' inside ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithm_fp.dispatch.c
  CCompilerOpt._parse_target_tokens[1934] : skip targets (SSE2 AVX512F AVX2) not part of baseline or dispatch-able features
  CCompilerOpt._parse_target_tokens[1958] : policy 'MAXOPT' is ON
  CCompilerOpt._parse_policy_maxopt[2067] : debug mode is detected, policy 'maxopt' is skipped.
  CCompilerOpt._generate_config[2501] : generate dispatched config ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithm_fp.dispatch.h
  CCompilerOpt.parse_targets[1763] : looking for '@targets' inside ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithmetic.dispatch.c
  CCompilerOpt._parse_target_tokens[1934] : skip targets (VSX2 AVX512F SSE2 AVX512_SKX AVX2 NEON SSE41) not part of baseline or dispatch-able features
  CCompilerOpt._parse_target_tokens[1958] : policy 'MAXOPT' is ON
  CCompilerOpt._parse_policy_maxopt[2067] : debug mode is detected, policy 'maxopt' is skipped.
  CCompilerOpt._generate_config[2501] : generate dispatched config ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithmetic.dispatch.h
  CCompilerOpt.parse_targets[1763] : looking for '@targets' inside ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_trigonometric.dispatch.c
  CCompilerOpt._parse_target_tokens[1934] : skip targets (VSX2 (FMA3 AVX2) NEON_VFPV4 AVX512F) not part of baseline or dispatch-able features
  CCompilerOpt._parse_target_tokens[1958] : policy 'MAXOPT' is ON
  CCompilerOpt._parse_policy_maxopt[2067] : debug mode is detected, policy 'maxopt' is skipped.
  CCompilerOpt._generate_config[2501] : generate dispatched config ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_trigonometric.dispatch.h
  CCompilerOpt.parse_targets[1763] : looking for '@targets' inside ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_exponent_log.dispatch.c
  CCompilerOpt._parse_target_tokens[1934] : skip targets ((FMA3 AVX2) AVX512_SKX AVX512F) not part of baseline or dispatch-able features
  CCompilerOpt._parse_target_tokens[1958] : policy 'MAXOPT' is ON
  CCompilerOpt._parse_policy_maxopt[2067] : debug mode is detected, policy 'maxopt' is skipped.
  CCompilerOpt._generate_config[2501] : generate dispatched config ->  build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_exponent_log.dispatch.h
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath
  compile options: '-DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_ATLAS_INFO=3 -DHAVE_CBLAS -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy -Ibuild/src.macosx-10.9-universal2-3.11/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  extra options: '-msse3 -I/System/Library/Frameworks/vecLib.framework/Headers'
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithm_fp.dispatch.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_arithmetic.dispatch.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_unary_fp.dispatch.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_exponent_log.dispatch.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops_trigonometric.dispatch.c
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_add_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_add_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_subtract_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_subtract_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_multiply_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_multiply_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_divide_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_divide_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  4 warnings generated.
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_add_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_add_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_subtract_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_subtract_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_multiply_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_multiply_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  numpy/core/src/umath/loops_arithm_fp.dispatch.c.src:454:1: warning: unused function 'run_binary_simd_divide_LONGDOUBLE' [-Wunused-function]
  run_binary_simd_divide_LONGDOUBLE(char **args, npy_intp const *dimensions, npy_intp const *steps)
  ^
  4 warnings generated.
  compiling C sources
  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g
  
  creating build/temp.macosx-10.9-universal2-3.11/numpy/core/src/multiarray
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort
  creating build/temp.macosx-10.9-universal2-3.11/numpy/core/src/umath
  creating build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/common
  compile options: '-DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_ATLAS_INFO=3 -DHAVE_CBLAS -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy -Ibuild/src.macosx-10.9-universal2-3.11/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c'
  extra options: '-msse3 -I/System/Library/Frameworks/vecLib.framework/Headers'
  clang: numpy/core/src/multiarray/abstractdtypes.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/arraytypes.c
  clang: numpy/core/src/multiarray/array_assign_scalar.c
  clang: numpy/core/src/multiarray/common.c
  clang: numpy/core/src/multiarray/buffer.c
  clang: numpy/core/src/multiarray/convert_datatype.c
  clang: numpy/core/src/multiarray/datetime.c
  clang: numpy/core/src/multiarray/datetime_busdaycal.c
  numpy/core/src/multiarray/convert_datatype.c:249:9: warning: comparison of nonnull parameter 'dtype' equal to a null pointer is 'false' on first encounter [-Wtautological-pointer-compare]
      if (dtype == NULL) {
          ^~~~~    ~~~~
  build/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy/__multiarray_api.h:112:40: note: declared 'nonnull' here
  NPY_NO_EXPORT NPY_STEALS_REF_TO_ARG(2) NPY_GCC_NONNULL(2) PyObject * PyArray_CastToType \
                                         ^
  numpy/core/include/numpy/npy_common.h:81:43: note: expanded from macro 'NPY_GCC_NONNULL'
  #define NPY_GCC_NONNULL(n) __attribute__((nonnull(n)))
                                            ^
  numpy/core/src/multiarray/arraytypes.c.src:65:26: error: expression is not assignable
      Py_TYPE(&new_fields) = NULL;
      ~~~~~~~~~~~~~~~~~~~~ ^
  clang: numpy/core/src/multiarray/alloc.c
  clang: numpy/core/src/multiarray/array_assign_array.c
  clang: numpy/core/src/multiarray/common_dtype.c
  1 error generated.
  clang: numpy/core/src/multiarray/dragon4.c
  clang: numpy/core/src/multiarray/descriptor.c
  clang: numpy/core/src/multiarray/arrayobject.c
  clang: numpy/core/src/multiarray/convert.c
  1 warning generated.
  clang: numpy/core/src/multiarray/arrayfunction_override.c
  clang: numpy/core/src/multiarray/calculation.c
  numpy/core/src/multiarray/convert_datatype.c:249:9: warning: comparison of nonnull parameter 'dtype' equal to a null pointer is 'false' on first encounter [-Wtautological-pointer-compare]
      if (dtype == NULL) {
          ^~~~~    ~~~~
  build/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy/__multiarray_api.h:112:40: note: declared 'nonnull' here
  NPY_NO_EXPORT NPY_STEALS_REF_TO_ARG(2) NPY_GCC_NONNULL(2) PyObject * PyArray_CastToType \
                                         ^
  numpy/core/include/numpy/npy_common.h:81:43: note: expanded from macro 'NPY_GCC_NONNULL'
  #define NPY_GCC_NONNULL(n) __attribute__((nonnull(n)))
                                            ^
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/einsum_sumprod.c
  clang: numpy/core/src/multiarray/hashdescr.c
  1 warning generated.
  clang: numpy/core/src/multiarray/conversion_utils.c
  clang: numpy/core/src/multiarray/item_selection.c
  clang: numpy/core/src/multiarray/compiled_base.c
  clang: numpy/core/src/multiarray/datetime_strings.c
  clang: numpy/core/src/multiarray/dtype_transfer.c
  clang: numpy/core/src/multiarray/legacy_dtype_implementation.c
  clang: numpy/core/src/multiarray/dtypemeta.c
  clang: numpy/core/src/multiarray/ctors.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/lowlevel_strided_loops.c
  clang: numpy/core/src/multiarray/datetime_busday.c
  clang: numpy/core/src/multiarray/methods.c
  clang: numpy/core/src/multiarray/nditer_api.c
  clang: numpy/core/src/multiarray/number.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/einsum.c
  clang: numpy/core/src/multiarray/iterators.c
  numpy/core/src/multiarray/einsum.c.src:408:32: warning: unknown warning group '-Wmaybe-uninitialized', ignored [-Wunknown-warning-option]
  #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
                                 ^
  clang: numpy/core/src/multiarray/shape.c
  clang: numpy/core/src/multiarray/refcount.c
  clang: numpy/core/src/multiarray/multiarraymodule.c
  1 warning generated.
  numpy/core/src/multiarray/einsum.c.src:408:32: warning: unknown warning group '-Wmaybe-uninitialized', ignored [-Wunknown-warning-option]
  #pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
                                 ^
  clang: numpy/core/src/multiarray/sequence.c
  1 warning generated.
  clang: numpy/core/src/multiarray/strfuncs.c
  clang: numpy/core/src/multiarray/usertypes.c
  clang: numpy/core/src/multiarray/scalarapi.c
  clang: numpy/core/src/multiarray/temp_elide.c
  clang: numpy/core/src/multiarray/nditer_constr.c
  clang: numpy/core/src/multiarray/vdot.c
  clang: numpy/core/src/multiarray/typeinfo.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/mergesort.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/quicksort.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/scalartypes.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/radixsort.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/selection.c
  clang: numpy/core/src/multiarray/nditer_pywrap.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/timsort.c
  clang: numpy/core/src/umath/umathmodule.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/matmul.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/nditer_templ.c
  clang: numpy/core/src/umath/reduction.c
  clang: numpy/core/src/umath/extobj.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/loops.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/scalarmath.c
  clang: numpy/core/src/multiarray/flagsobject.c
  clang: numpy/core/src/multiarray/getset.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/umath/clip.c
  clang: numpy/core/src/umath/override.c
  clang: numpy/core/src/common/array_assign.c
  clang: numpy/core/src/common/npy_argparse.c
  clang: numpy/core/src/common/mem_overlap.c
  clang: numpy/core/src/common/npy_longdouble.c
  clang: numpy/core/src/common/ucsnarrow.c
  clang: numpy/core/src/umath/ufunc_object.c
  clang: numpy/core/src/common/ufunc_override.c
  clang: numpy/core/src/common/cblasfuncs.c
  clang: numpy/core/src/common/numpyos.c
  clang: numpy/core/src/common/python_xerbla.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/common/npy_cpu_features.c
  numpy/core/src/common/npy_cpu_features.c.src:125:1: warning: unused function 'npy__cpu_baseline_fid' [-Wunused-function]
  npy__cpu_baseline_fid(const char *feature)
  ^
  numpy/core/src/common/npy_cpu_features.c.src:138:1: warning: unused function 'npy__cpu_dispatch_fid' [-Wunused-function]
  npy__cpu_dispatch_fid(const char *feature)
  ^
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/binsearch.c
  2 warnings generated.
  numpy/core/src/common/npy_cpu_features.c.src:125:1: warning: unused function 'npy__cpu_baseline_fid' [-Wunused-function]
  npy__cpu_baseline_fid(const char *feature)
  ^
  numpy/core/src/common/npy_cpu_features.c.src:138:1: warning: unused function 'npy__cpu_dispatch_fid' [-Wunused-function]
  npy__cpu_dispatch_fid(const char *feature)
  ^
  2 warnings generated.
  clang: numpy/core/src/umath/ufunc_type_resolution.c
  clang: build/src.macosx-10.9-universal2-3.11/numpy/core/src/npysort/heapsort.c
  clang: numpy/core/src/multiarray/mapping.c
  error: Command "clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DNO_ATLAS_INFO=3 -DHAVE_CBLAS -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/include/numpy -Ibuild/src.macosx-10.9-universal2-3.11/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/common -Ibuild/src.macosx-10.9-universal2-3.11/numpy/core/src/npymath -c build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/arraytypes.c -o build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/arraytypes.o -MMD -MF build/temp.macosx-10.9-universal2-3.11/build/src.macosx-10.9-universal2-3.11/numpy/core/src/multiarray/arraytypes.o.d -msse3 -I/System/Library/Frameworks/vecLib.framework/Headers" failed with exit status 1
  
  ########### EXT COMPILER OPTIMIZATION ###########
  Platform      :
    Architecture: unsupported
    Compiler    : clang
  
  CPU baseline  :
    Requested   : optimization disabled
    Enabled     : none
    Flags       : none
    Extra checks: none
    Requested   : optimization disabled
  
  CPU dispatch  :
    Enabled     : none
    Generated   : none
  CCompilerOpt.cache_flush[804] : write cache to path -> /private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/build/temp.macosx-10.9-universal2-3.11/ccompiler_opt_cache_ext.py
  
  ########### CLIB COMPILER OPTIMIZATION ###########
  Platform      :
    Architecture: unsupported
    Compiler    : clang
  
  CPU baseline  :
    Requested   : optimization disabled
    Enabled     : none
    Flags       : none
    Extra checks: none
    Requested   : optimization disabled
  
  CPU dispatch  :
    Enabled     : none
    Generated   : none
  CCompilerOpt.cache_flush[804] : write cache to path -> /private/var/folders/js/z0nzng056v5b32z5_jfxwj_r0000gn/T/pip-install-bqxq7z4_/numpy_7a95a59cf3dd4798b2039e070138356e/build/temp.macosx-10.9-universal2-3.11/ccompiler_opt_cache_clib.py
  ----------------------------------------
  ERROR: Failed building wheel for numpy
Failed to build numpy
ERROR: Could not build wheels for numpy which use PEP 517 and cannot be installed directly

----------
components: macOS
messages: 403325
nosy: Joshuah143, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pip install numpy not working in 3.11.0a on macOS 11.6
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct  6 16:21:03 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Oct 2021 20:21:03 +0000
Subject: [New-bugs-announce] [issue45395] Frozen stdlib modules are
 discarded if custom frozen modules added.
Message-ID: <1633551663.5.0.531821025802.issue45395@roundup.psfhosted.org>


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

The mechanism to add custom frozen modules to the Python runtime is to set PyImport_FrozenModules (see Python/frozen.c) to some new array.  This means that the default frozen modules (from _PyImport_FrozenModules) are no longer used unless explicitly added to the custom array.  This is unlikely to be what the user wants.  It's especially problematic since it's easy to not realize this (or forget) and forgetting essential modules (like _frozen_importlib) will cause crashes.

It would probably make more sense to have PyImport_FrozenModules be an array of *additional* frozen modules, defaulting to an empty array.  Before going down that route we need to be sure that isn't going to break folks that are accommodating the existing behavior.

----------
components: Interpreter Core
messages: 403335
nosy: brett.cannon, eric.snow, lemburg
priority: normal
severity: normal
stage: needs patch
status: open
title: Frozen stdlib modules are discarded if custom frozen modules added.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct  6 16:22:14 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Oct 2021 20:22:14 +0000
Subject: [New-bugs-announce] [issue45396] Custom frozen modules get ignored.
Message-ID: <1633551734.9.0.785349509784.issue45396@roundup.psfhosted.org>


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

Recently we added the "-X frozen_modules" CLI option to control whether or not (non-essential) frozen modules get used.  Currently the default is "off", though the plan is to make the default "on".  Regardless, this is problematic for executables with custom frozen modules (where PyImport_FrozenModules is overridden).  If there are custom frozen modules then they should always be used.

Note that there are already other problems with custom frozen modules, to be addressed separately.  (See bpo-45395.)

----------
assignee: eric.snow
components: Interpreter Core
messages: 403336
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Custom frozen modules get ignored.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct  6 23:12:17 2021
From: report at bugs.python.org (jg)
Date: Thu, 07 Oct 2021 03:12:17 +0000
Subject: [New-bugs-announce] [issue45397] Doc for turtle.write missing the
 tuple part of the font param in 3.10+
Message-ID: <1633576337.95.0.961564337357.issue45397@roundup.psfhosted.org>


New submission from jg <jggammon at hotmail.com>:

In the version 3.10 and 3.11 python turtle doc, the turtle.write line shows font without it's tuple parenthesis. Something change in 3.10 that makes it look like font='Arial' and 8 and 'normal' are 3 separate parameters, when it should be one tuple parameter font=(x,y,z).

Ex. of wrong entry (URL=https://docs.python.org/3.11/library/turtle.html#turtle.write)
line=turtle.write(arg, move=False, align='left', font='Arial', 8, 'normal')

Ex. of correct entry (https://docs.python.org/3.9/library/turtle.html#turtle.write)
line=turtle.write(arg, move=False, align="left", font=("Arial", 8, "normal"))

----------
assignee: docs at python
components: Documentation
messages: 403348
nosy: docs at python, jggammon
priority: normal
severity: normal
status: open
title: Doc for turtle.write missing the tuple part of the font param in 3.10+
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  7 04:58:12 2021
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdC10Lk=?=)
Date: Thu, 07 Oct 2021 08:58:12 +0000
Subject: [New-bugs-announce] [issue45398] Bugs in set operations in 3.8.10
 (detected in Win7)
Message-ID: <1633597092.06.0.36085946328.issue45398@roundup.psfhosted.org>


New submission from ??????? <smi-alexey at yandex.ru>:

x = set('abcde')
y = set('bdxyz')

x | y
result:
     {'b', 'c', 'd', 'z', 'x', 'a', 'y'}
but should be:
     {'b', 'c', 'd', 'z', 'x', 'a', 'y', 'e'}

----------
messages: 403362
nosy: bfx683
priority: normal
severity: normal
status: open
title: Bugs in set operations in 3.8.10 (detected in Win7)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct  7 05:36:56 2021
From: report at bugs.python.org (ramikg)
Date: Thu, 07 Oct 2021 09:36:56 +0000
Subject: [New-bugs-announce] [issue45399] Remove hostflags from PySSLContext
Message-ID: <1633599416.0.0.711610272152.issue45399@roundup.psfhosted.org>


New submission from ramikg <ramikgold at gmail.com>:

The PySSLContext struct mentions that "OpenSSL has no API to get hostflags from X509_VERIFY_PARAM* struct. We have to maintain our own copy".
Since OpenSSL 1.1.0i added the function X509_VERIFY_PARAM_get_hostflags, this statement is no longer true.
Because Python 3.10 requires OpenSSL 1.1.1 (PEP 644), we no longer have to maintain a copy of the host flags.

The related PR removes the hostflags member from the PySSLContext struct.

----------
assignee: christian.heimes
components: SSL
messages: 403368
nosy: christian.heimes, ramikg
priority: normal
pull_requests: 27117
severity: normal
status: open
title: Remove hostflags from PySSLContext
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Oct  7 05:47:27 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 07 Oct 2021 09:47:27 +0000
Subject: [New-bugs-announce] [issue45400]
 test_name_error_suggestions_do_not_trigger_for_too_many_locals:
 AssertionError: 'a1' unexpectedly found in Traceback
Message-ID: <1633600047.69.0.0952962991188.issue45400@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

The test_name_error_suggestions_do_not_trigger_for_too_many_locals test fails with the to-be-released 3.11.0a1:

======================================================================
FAIL: test_name_error_suggestions_do_not_trigger_for_too_many_locals (test.test_exceptions.NameErrorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.11.0a1/Lib/test/test_exceptions.py", line 1843, in test_name_error_suggestions_do_not_trigger_for_too_many_locals
    self.assertNotIn("a1", err.getvalue())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'a1' unexpectedly found in 'Traceback (most recent call last):\n  File "/builddir/build/BUILD/Python-3.11.0a1/Lib/test/test_exceptions.py", line 1838, in test_name_error_suggestions_do_not_trigger_for_too_many_locals\n    f()\n    ^^^\n  File "/builddir/build/BUILD/Python-3.11.0a1/Lib/test/test_exceptions.py", line 1835, in f\n    print(a0)\n          ^^\nNameError: name \'a0\' is not defined\n'

----------------------------------------------------------------------
Ran 1 test in 0.016s


I believe it is the version string that triggers this failure.

----------
messages: 403370
nosy: hroncok, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_name_error_suggestions_do_not_trigger_for_too_many_locals: AssertionError: 'a1' unexpectedly found in Traceback
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct  7 05:47:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2021 09:47:34 +0000
Subject: [New-bugs-announce] [issue45401] logging TimedRotatingFileHandler
 must not rename devices like /dev/null
Message-ID: <1633600054.24.0.602209276715.issue45401@roundup.psfhosted.org>


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

One way to disable logging in a configuration file is to use /dev/null as the filename for logs. It is fine to use that with FileHandler.

The problem is when TimedRotatingFileHandler is used. When Python decides to rotate the "file", it calls os.rename() on /dev/null *device* and create a new /dev/null *file* which will be quickly filled by all applications on the system writing into /dev/null.

The problem is only possible if the process is allowed to rename the device /dev/null. For example, a regular user gets a permission error.

I see different options:

* TimedRotatingFileHandler should disable rotation if it detects that the file is a device (not a regular file)
* logging should switch to NullHandler if filename is equal to os.path.devnull.

I guess that the problem is the same if the filename points to a socket or a named pipe.


RotatingFileHandler may also be affected, I didn't check.


... I'm quite sure that I had the same issue with Twisted years ago, but I don't recall the details :-) Twisted didn't use the logging module if I recall correctly.


RHEL downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=2009200

----------
components: Library (Lib)
messages: 403371
nosy: vinay.sajip, vstinner
priority: normal
severity: normal
status: open
title: logging TimedRotatingFileHandler must not rename devices like /dev/null
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct  7 06:05:28 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 07 Oct 2021 10:05:28 +0000
Subject: [New-bugs-announce] [issue45402] ERROR: test_sundry
 (test.test_tools.test_sundry.TestSundryScripts): SystemExit: ERROR: missing
 _freeze_module
Message-ID: <1633601128.84.0.599818105628.issue45402@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

When we build Python 3.10.0a1 (from the git tag) in Fedora, we see:

======================================================================
ERROR: test_sundry (test.test_tools.test_sundry.TestSundryScripts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.11.0a1/Lib/test/test_tools/test_sundry.py", line 43, in test_sundry
    import_tool(name)
    ^^^^^^^^^^^^^^^^^
  File "/builddir/build/BUILD/Python-3.11.0a1/Lib/test/test_tools/__init__.py", line 35, in import_tool
    return importlib.import_module(toolname)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/builddir/build/BUILD/Python-3.11.0a1/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1072, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1044, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1015, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 689, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 894, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/builddir/build/BUILD/Python-3.11.0a1/Tools/scripts/freeze_modules.py", line 37, in <module>
    sys.exit("ERROR: missing _freeze_module")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SystemExit: ERROR: missing _freeze_module

----------------------------------------------------------------------
Ran 3 tests in 0.209s


I see in the build log we use Programs/_freeze_module regularly in the build process, so no idea why this fails. I'll try to come up with a reporducer.

----------
components: Tests
messages: 403377
nosy: hroncok, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: ERROR: test_sundry (test.test_tools.test_sundry.TestSundryScripts): SystemExit: ERROR: missing _freeze_module
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct  7 07:25:38 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2021 11:25:38 +0000
Subject: [New-bugs-announce] [issue45403] test_sys: test_stdlib_dir() fails
 when Python is built outside the source tree
Message-ID: <1633605938.68.0.349965351809.issue45403@roundup.psfhosted.org>


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

Reproduce the issue:
---
# go to Python source tree
mkdir build
cd build
../configure
make
./python -m test test_sys
---

Output:

======================================================================
FAIL: test_stdlib_dir (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/main/Lib/test/test_sys.py", line 1005, in test_stdlib_dir
    self.assertEqual(actual, expected)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: '/home/vstinner/python/main/build/../Lib' != '/home/vstinner/python/main/Lib'
- /home/vstinner/python/main/build/../Lib
?                            ---------
+ /home/vstinner/python/main/Lib


Attached PR fix the issue.

----------
components: Tests
messages: 403389
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_sys: test_stdlib_dir() fails when Python is built outside the source tree
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct  7 07:57:28 2021
From: report at bugs.python.org (Diego Alonso)
Date: Thu, 07 Oct 2021 11:57:28 +0000
Subject: [New-bugs-announce] [issue45404] Undefined I_* macros when building
 3.10 on Ubuntu?
Message-ID: <1633607848.34.0.992499900554.issue45404@roundup.psfhosted.org>


New submission from Diego Alonso <diego at mathisart.org>:

Trying to build Python 3.10 on Ubuntu 20.04. It builds everything but the fcntl module; ie. at the end it says:

Failed to build these modules:
fcntl.

Here are the compilation errors. It's trying to use certain macros that are undefined: I_PUSH, I_POP, I_LOOK, I_FLUSH, I_FLUSHBAND, I_SETSIG, I_GETSIG, I_FIND, I_PEEK, I_SRDOPT, I_GRDOPT, I_NREAD, I_FDINSERT, I_STR, I_SWROPT, I_SENDFD, I_RECVFD, I_LIST, I_ATMARK, I_CKBAND, I_GETBAND, I_CANPUT, I_SETCLTIME, I_LINK, I_UNLINK, I_PLINK, I_PUNLINK

----------------------------------------------------------------
Modules/_xxsubinterpretersmodule.o
In file included from ./Include/Python.h:140,
                 from /home/da/git/Python-3.10.0/Modules/fcntlmodule.c:6:
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c: In function ?all_ins?:
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:614:33: error: ?I_PUSH? undeclared (first use in this function)
  614 |     if (PyModule_AddIntMacro(m, I_PUSH)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:614:33: note: each undeclared identifier is reported only once for each function it appears in
  614 |     if (PyModule_AddIntMacro(m, I_PUSH)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:615:33: error: ?I_POP? undeclared (first use in this function)
  615 |     if (PyModule_AddIntMacro(m, I_POP)) return -1;
      |                                 ^~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:616:33: error: ?I_LOOK? undeclared (first use in this function); did you mean ?F_LOCK??
  616 |     if (PyModule_AddIntMacro(m, I_LOOK)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:617:33: error: ?I_FLUSH? undeclared (first use in this function); did you mean ?CFLUSH??
  617 |     if (PyModule_AddIntMacro(m, I_FLUSH)) return -1;
      |                                 ^~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:618:33: error: ?I_FLUSHBAND? undeclared (first use in this function)
  618 |     if (PyModule_AddIntMacro(m, I_FLUSHBAND)) return -1;
      |                                 ^~~~~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:619:33: error: ?I_SETSIG? undeclared (first use in this function); did you mean ?F_SETSIG??
  619 |     if (PyModule_AddIntMacro(m, I_SETSIG)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:620:33: error: ?I_GETSIG? undeclared (first use in this function); did you mean ?F_GETSIG??
  620 |     if (PyModule_AddIntMacro(m, I_GETSIG)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:621:33: error: ?I_FIND? undeclared (first use in this function)
  621 |     if (PyModule_AddIntMacro(m, I_FIND)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:622:33: error: ?I_PEEK? undeclared (first use in this function)
  622 |     if (PyModule_AddIntMacro(m, I_PEEK)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:623:33: error: ?I_SRDOPT? undeclared (first use in this function)
  623 |     if (PyModule_AddIntMacro(m, I_SRDOPT)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:624:33: error: ?I_GRDOPT? undeclared (first use in this function)
  624 |     if (PyModule_AddIntMacro(m, I_GRDOPT)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:625:33: error: ?I_NREAD? undeclared (first use in this function); did you mean ?FIONREAD??
  625 |     if (PyModule_AddIntMacro(m, I_NREAD)) return -1;
      |                                 ^~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:626:33: error: ?I_FDINSERT? undeclared (first use in this function)
  626 |     if (PyModule_AddIntMacro(m, I_FDINSERT)) return -1;
      |                                 ^~~~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:627:33: error: ?I_STR? undeclared (first use in this function)
  627 |     if (PyModule_AddIntMacro(m, I_STR)) return -1;
      |                                 ^~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:628:33: error: ?I_SWROPT? undeclared (first use in this function)
  628 |     if (PyModule_AddIntMacro(m, I_SWROPT)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
gcc -pthread -shared -fno-semantic-interposition -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -fprofile-generate build/temp.linux-x86_64-3.10/home/da/git/Python-3.10.0/Modules/_contextvarsmodule.o -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib -o build/lib.linux-x86_64-3.10/_contextvars.cpython-310-x86_64-linux-gnu.so
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:633:33: error: ?I_SENDFD? undeclared (first use in this function)
  633 |     if (PyModule_AddIntMacro(m, I_SENDFD)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:634:33: error: ?I_RECVFD? undeclared (first use in this function)
  634 |     if (PyModule_AddIntMacro(m, I_RECVFD)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:635:33: error: ?I_LIST? undeclared (first use in this function)
  635 |     if (PyModule_AddIntMacro(m, I_LIST)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:636:33: error: ?I_ATMARK? undeclared (first use in this function)
  636 |     if (PyModule_AddIntMacro(m, I_ATMARK)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:637:33: error: ?I_CKBAND? undeclared (first use in this function)
  637 |     if (PyModule_AddIntMacro(m, I_CKBAND)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:638:33: error: ?I_GETBAND? undeclared (first use in this function)
  638 |     if (PyModule_AddIntMacro(m, I_GETBAND)) return -1;
      |                                 ^~~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:639:33: error: ?I_CANPUT? undeclared (first use in this function)
  639 |     if (PyModule_AddIntMacro(m, I_CANPUT)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:640:33: error: ?I_SETCLTIME? undeclared (first use in this function)
  640 |     if (PyModule_AddIntMacro(m, I_SETCLTIME)) return -1;
      |                                 ^~~~~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:644:33: error: ?I_LINK? undeclared (first use in this function); did you mean ?EMLINK??
  644 |     if (PyModule_AddIntMacro(m, I_LINK)) return -1;
      |                                 ^~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:645:33: error: ?I_UNLINK? undeclared (first use in this function)
  645 |     if (PyModule_AddIntMacro(m, I_UNLINK)) return -1;
      |                                 ^~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:646:33: error: ?I_PLINK? undeclared (first use in this function)
  646 |     if (PyModule_AddIntMacro(m, I_PLINK)) return -1;
      |                                 ^~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |                                                                   ^
/home/da/git/Python-3.10.0/Modules/fcntlmodule.c:647:33: error: ?I_PUNLINK? undeclared (first use in this function)
  647 |     if (PyModule_AddIntMacro(m, I_PUNLINK)) return -1;
      |                                 ^~~~~~~~~
./Include/modsupport.h:154:67: note: in definition of macro ?PyModule_AddIntMacro?
  154 | #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c)
      |

----------
components: Build
messages: 403396
nosy: etale-cohomology
priority: normal
severity: normal
status: open
title: Undefined I_* macros when building 3.10 on Ubuntu?
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  7 08:56:37 2021
From: report at bugs.python.org (debohman)
Date: Thu, 07 Oct 2021 12:56:37 +0000
Subject: [New-bugs-announce] [issue45405] Python 3.10.0 does not configure
 on darwin using public llvm / clang
Message-ID: <1633611397.74.0.642629173294.issue45405@roundup.psfhosted.org>


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

% CC=clang CXX=clang++ ./configure --enable-optimizations --with-lto
checking build system type... x86_64-apple-darwin16.7.0
checking host system type... x86_64-apple-darwin16.7.0
checking for python3.10... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "darwin"
checking for gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ISO C89... none needed
checking how to run the C preprocessor... clang -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for a sed that does not truncate output... /usr/local/bin/sed
checking for --with-cxx-main=<compiler>... no
checking for the platform triplet based on compiler characteristics... darwin
configure: error: internal configure error for the platform triplet, please file a bug report

The problem occurs here at line 5382 of configure:

if test x$PLATFORM_TRIPLET != x && test x$MULTIARCH != x; then
  if test x$PLATFORM_TRIPLET != x$MULTIARCH; then
    as_fn_error $? "internal configure error for the platform triplet, please file a bug report" "$LINENO" 5
  fi

The problem is that $PLATFORM_TRIPLET is set to darwin (which appears to be correct) and $MULTIARCH is set thus:

MULTIARCH=$($CC --print-multiarch 2>/dev/null)

which evaluates to x86_64-apple-darwin16.7.0.

This is with the public llvm / clang version 13.0.0.

If you set MULTIARCH=darwin in configure, python configures, builds and runs.

----------
components: Build
messages: 403401
nosy: debohman
priority: normal
severity: normal
status: open
title: Python 3.10.0 does not configure on darwin using public llvm / clang
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  7 09:57:49 2021
From: report at bugs.python.org (=?utf-8?q?Miroslav_Such=C3=BD?=)
Date: Thu, 07 Oct 2021 13:57:49 +0000
Subject: [New-bugs-announce] [issue45406] inspect.getouterframes()
 tracebacks when $CWD does not exists
Message-ID: <1633615069.33.0.311671101448.issue45406@roundup.psfhosted.org>


New submission from Miroslav Such? <msuchy at redhat.com>:

When you exec inspect.getouterframes() in directory, which no longer exists, then you get traceback, because the code traverse to os.getcwd() which fails.

Reproducer:

$ mkdir /tmp/bar
$ cd /tmp/bar
$ rmdir /tmp/bar
$ python3
Python 3.10.0rc2 (default, Sep  8 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> inspect.getouterframes(inspect.currentframe())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.10/inspect.py", line 1653, in getouterframes
    frameinfo = (frame,) + getframeinfo(frame, context)
  File "/usr/lib64/python3.10/inspect.py", line 1623, in getframeinfo
    filename = getsourcefile(frame) or getfile(frame)
  File "/usr/lib64/python3.10/inspect.py", line 829, in getsourcefile
    module = getmodule(object, filename)
  File "/usr/lib64/python3.10/inspect.py", line 861, in getmodule
    file = getabsfile(object, _filename)
  File "/usr/lib64/python3.10/inspect.py", line 845, in getabsfile
    return os.path.normcase(os.path.abspath(_filename))
  File "/usr/lib64/python3.10/posixpath.py", line 383, in abspath
    cwd = os.getcwd()
FileNotFoundError: [Errno 2] No such file or directory

----------
components: Library (Lib)
messages: 403410
nosy: msuchy at redhat.com
priority: normal
severity: normal
status: open
title: inspect.getouterframes() tracebacks when $CWD does not exists
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct  7 13:49:27 2021
From: report at bugs.python.org (youknowone)
Date: Thu, 07 Oct 2021 17:49:27 +0000
Subject: [New-bugs-announce] [issue45407] Support buffer protocol for
 _struct.Struct format argument
Message-ID: <1633628967.32.0.849545614693.issue45407@roundup.psfhosted.org>


New submission from youknowone <jeong at youknowone.org>:

This feature is commented as `XXX` for years.

https://github.com/python/cpython/blob/4e605666b08b8f863cbbbdaa34bb06988e648d26/Modules/_struct.c#L1478

Giving a bug tracker id or removing the comment will clarify the problem.

----------
components: Library (Lib)
messages: 403426
nosy: youknowone
priority: normal
pull_requests: 27126
severity: normal
status: open
title: Support buffer protocol for _struct.Struct format argument
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct  7 14:00:19 2021
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 07 Oct 2021 18:00:19 +0000
Subject: [New-bugs-announce] [issue45408] [fuzzer] Weird input with
 continuation and newlines causes null deref in parser
Message-ID: <1633629619.45.0.834198327625.issue45408@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

>From the newly added ast.literal_eval(x) fuzzer, the following string fed to ast.literal_eval will cause a null pointer in get_error_line:

\
(\
\

This can be recreated with:

? ./python          
Python 3.11.0a1+ (heads/fuzz_ast-dirty:6c942a86a4, Oct  6 2021, 16:27:52) [GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.literal_eval(r'''\
... \
... (\
... \ ''')
[1]    15464 segmentation fault  ./python


---------------
Raw ASAN report
---------------

	==85015==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f987730e08c bp 0x7fff7f8e8080 sp 0x7fff7f8e7838 T0)
==85015==The signal is caused by a READ memory access.
==85015==Hint: address points to the zero page.
    #0 0x7f987730e08c in strchr-avx2.S:57 /build/glibc-eX1tMB/glibc-2.31/sysdeps/x86_64/multiarch/strchr-avx2.S:57
    #1 0x4d7a58 in strchr /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:0
    #2 0x9f9d95 in get_error_line cpython3/Parser/pegen.c:406:25
    #3 0x9f9d95 in _PyPegen_raise_error_known_location cpython3/Parser/pegen.c:497:26
    #4 0x9fd492 in RAISE_ERROR_KNOWN_LOCATION cpython3/Parser/pegen.h:169:5
    #5 0xa00528 in raise_unclosed_parentheses_error cpython3/Parser/pegen.c:267:8
    #6 0xa00528 in _PyPegen_check_tokenizer_errors cpython3/Parser/pegen.c:1314:25
    #7 0x9ff9e3 in _PyPegen_run_parser cpython3/Parser/pegen.c:1352:17
    #8 0xa015c5 in _PyPegen_run_parser_from_string cpython3/Parser/pegen.c:1479:14
    #9 0xa805e9 in _PyParser_ASTFromString cpython3/Parser/peg_api.c:14:21
    #10 0x85f01a in Py_CompileStringObject cpython3/Python/pythonrun.c:1371:11
    #11 0xc0785f in builtin_compile_impl cpython3/Python/bltinmodule.c:841:14
    #12 0xc0785f in builtin_compile cpython3/Python/clinic/bltinmodule.c.h:249:20
    #13 0xb7b28e in cfunction_vectorcall_FASTCALL_KEYWORDS cpython3/Objects/methodobject.c:446:24
    #14 0x764f22 in call_function cpython3/Python/ceval.c:0
    #15 0x7482e6 in _PyEval_EvalFrameDefault cpython3/Python/ceval.c:4614:19
    #16 0x741225 in _PyEval_EvalFrame cpython3/Include/internal/pycore_ceval.h:46:12
    #17 0x741225 in _PyEval_Vector cpython3/Python/ceval.c:5636:24
    #18 0x57c510 in _PyFunction_Vectorcall cpython3/Objects/call.c:0
    #19 0x764f22 in call_function cpython3/Python/ceval.c:0
    #20 0x7482e6 in _PyEval_EvalFrameDefault cpython3/Python/ceval.c:4614:19
    #21 0x741225 in _PyEval_EvalFrame cpython3/Include/internal/pycore_ceval.h:46:12
    #22 0x741225 in _PyEval_Vector cpython3/Python/ceval.c:5636:24
    #23 0x57c510 in _PyFunction_Vectorcall cpython3/Objects/call.c:0
    #24 0x579def in _PyObject_VectorcallTstate /workspace/out/libfuzzer-address-x86_64/include/python3.11/cpython/abstract.h:114:11
    #25 0x579def in PyObject_CallOneArg /workspace/out/libfuzzer-address-x86_64/include/python3.11/cpython/abstract.h:184:12
    #26 0x579def in fuzz_ast_literal_eval cpython3/Modules/_xxtestfuzz/fuzzer.c:425:25
    #27 0x579def in _run_fuzz cpython3/Modules/_xxtestfuzz/fuzzer.c:443:14
    #28 0x579def in LLVMFuzzerTestOneInput cpython3/Modules/_xxtestfuzz/fuzzer.c:565:11
    #29 0x4725e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0
    #30 0x45deb2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
    #31 0x463965 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0
    #32 0x48c6b2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #33 0x7f98771aa0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16
    #34 0x43b16d in _start
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x18b08c)
==85015==ABORTING

----------
components: Parser
messages: 403427
nosy: ammar2, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: [fuzzer] Weird input with continuation and newlines causes null deref in parser
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct  7 20:09:01 2021
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Oct 2021 00:09:01 +0000
Subject: [New-bugs-announce] [issue45409] Support non-standard executables
 in venv
Message-ID: <1633651741.67.0.0706483725716.issue45409@roundup.psfhosted.org>


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

Currently the venv redirector on Windows is hardcoded for "python.exe" and "pythonw.exe". There is no good reason for this, and it's fairly easy to make the redirector able to invoke any executable in the base environment by inspecting its own name.

This would help support non-standard environments that include other entry points.

----------
assignee: steve.dower
components: Windows
messages: 403450
nosy: paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Support non-standard executables in venv
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  8 07:15:36 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Oct 2021 11:15:36 +0000
Subject: [New-bugs-announce] [issue45410] python -m test -jN: write stderr
 in stdout to get messages in order
Message-ID: <1633691736.44.0.338544053782.issue45410@roundup.psfhosted.org>


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

In buildbot logs, when a worker process is run, two pipes are created for stdout and stderr. The problem is that using two pipes produce an output which is hard to read.

Pseudo output:
---
stdout time 1
stdout time 2
stdout time 3
stderr time 1
stderr time 2
---

I would prefer:
---
stdout time 1
stderr time 1
stdout time 2
stderr time 2
stdout time 3
---

Real logs:
https://buildbot.python.org/all/#/builders/79/builds/870
---
0:01:10 load avg: 4.48 [236/427/1] test_ftplib failed (env changed) -- (...)
Warning -- Uncaught thread exception: Exception
Exception in thread Thread-67:
Traceback (most recent call last):
  (...)
Exception
test__all__ (test.test_ftplib.MiscTestCase) ... ok
test_abort (test.test_ftplib.TestFTPClass) ... ok
test_acct (test.test_ftplib.TestFTPClass) ... ok
test_all_errors (test.test_ftplib.TestFTPClass) ... ok
(...)
Ran 94 tests in 2.326s
---

The Warning is logged at the beginning, it's not possible to know which test emitted this warning.

I propose to write stdout and stderr of a worker process into a single pipe to keep messages order.

In the past, I saw buildbot logging stderr messages in a different color. But it no longer seems to be the case.

I'm working on a PR.

----------
components: Tests
messages: 403467
nosy: vstinner
priority: normal
severity: normal
status: open
title: python -m test -jN: write stderr in stdout to get messages in order
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  8 07:25:40 2021
From: report at bugs.python.org (Josephine Stolle)
Date: Fri, 08 Oct 2021 11:25:40 +0000
Subject: [New-bugs-announce] [issue45411] Add Mimetypes for Subtitle Files
Message-ID: <1633692340.99.0.107401828025.issue45411@roundup.psfhosted.org>


New submission from Josephine Stolle <josephine.stolle11 at gmail.com>:

Since Python is used for webdevelopment, it would be very beneficial for developers to have subtitle files as default mimetypes.

----------
components: Library (Lib)
messages: 403468
nosy: Josephine-Marie
priority: normal
pull_requests: 27137
severity: normal
status: open
title: Add Mimetypes for Subtitle Files
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/issue45411>
_______________________________________

From report at bugs.python.org  Fri Oct  8 09:39:11 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Oct 2021 13:39:11 +0000
Subject: [New-bugs-announce] [issue45412] [C API] Remove Py_OVERFLOWED(),
 Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()
Message-ID: <1633700351.81.0.101355063932.issue45412@roundup.psfhosted.org>


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

I propose to remove the following macros from the Python C API:

* Py_OVERFLOWED()
* _Py_SET_EDOM_FOR_NAN()
* Py_SET_ERRNO_ON_MATH_ERROR()
* Py_SET_ERANGE_IF_OVERFLOW()
* Py_ADJUST_ERANGE1()
* Py_ADJUST_ERANGE2()

Only Py_ADJUST_ERANGE1() and Py_ADJUST_ERANGE2() are still used by Python itself, other macros are no longer used since Python 2.7:

* Py_OVERFLOWED(): no longer used since Python 2.7
* _Py_SET_EDOM_FOR_NAN(): used by Py_SET_ERRNO_ON_MATH_ERROR() which is no longer used
* Py_SET_ERRNO_ON_MATH_ERROR(): no longer used since Python 2.6
* Py_SET_ERANGE_IF_OVERFLOW(): no longer used since Python 2.4
* Py_ADJUST_ERANGE1(): used by Objects/floatobject.c
* Py_ADJUST_ERANGE2(): used by Objects/complexobject.c

I searched for these macros in the PyPI top 5000 modules: none of these macros are used. There is a single match: frozendict-2.0.6 which contains a Include/pyport.h copy, but it doesn't use these macros.

--

Py_OVERFLOWED() was used by long_true_divide() and PyLong_AsDouble() in Python 2.6, but Python 2.7 no longer used them.


(1) Py_OVERFLOWED() call in long_true_divide() was removed in Python 2.7 by bpo-1811:

commit 465728364749e903fb4293b2f7a266b58de6bde4
Author: Mark Dickinson <dickinsm at gmail.com>
Date:   Sun Dec 27 14:55:57 2009 +0000

    Issue #1811:  Improve accuracy and consistency of true division for integers.


(2) Py_OVERFLOWED() call in PyLong_AsDouble() was removed in Python 2.7 by bpo-3166:

commit 6736cf8d20b67b74e8e959622132963285156242
Author: Mark Dickinson <dickinsm at gmail.com>
Date:   Mon Apr 20 21:13:33 2009 +0000

    Issue #3166: Make long -> float (and int -> float) conversions
    correctly rounded, using round-half-to-even.  This ensures that the
    value of float(n) doesn't depend on whether we're using 15-bit digits
    or 30-bit digits for Python longs.

--

Py_SET_ERRNO_ON_MATH_ERROR() and Py_SET_ERANGE_IF_OVERFLOW() were used in Objects/mathmodule.c in Python 2.5.


(1) The last call to Py_SET_ERRNO_ON_MATH_ERROR() was removed by in Python 2.6 by:

commit 6f34109384f3a78d5f4f8bdd418a89caca19631e
Author: Christian Heimes <christian at cheimes.de>
Date:   Fri Apr 18 23:13:07 2008 +0000

    I finally got the time to update and merge Mark's and my trunk-math branch. The patch is collaborated work of Mark Dickinson and me. It was mostly done a few months ago. The patch fixes a lot of loose ends and edge cases related to operations with NaN, INF, very small values and complex math.
    
    The patch also adds acosh, asinh, atanh, log1p and copysign to all platforms. Finally it fixes differences between platforms like different results or exceptions for edge cases. Have fun :)


(2) The last call to Py_SET_ERANGE_IF_OVERFLOW() was removed in Python 2.4 by:

commit 77d9a3effa21b8987ceac26d67ad676e1c5afb49
Author: Hye-Shik Chang <hyeshik at gmail.com>
Date:   Mon Mar 22 08:43:55 2004 +0000

    Patch #871657: Set EDOM for `nan' return values on FreeBSD and OpenBSD.
    This fixes a problem that math.sqrt(-1) doesn't raise math.error.

----------
components: C API
messages: 403473
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Remove Py_OVERFLOWED(), Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  8 13:50:02 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 08 Oct 2021 17:50:02 +0000
Subject: [New-bugs-announce] [issue45413] Add install scheme for virtual
 environment
Message-ID: <1633715402.49.0.434363843275.issue45413@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

Python 3.10 introduced sysconfig._get_preferred_schemes[1], a mechanism to allow downstream distributors to overwrite the default install scheme.
This is done to support downstream modifications where distributors change the installation layout (eg. different site-packages directory). So, distributors will change the default scheme to one that correctly represents their layout.

This presents an issue for projects/people that need to bootstrap virtual environments, like virtualenv (see [2]). As distributors might now be customizing the default install scheme, there is no guarantee that the information returned by sysconfig.get_default_scheme/get_paths is correct for the virtual environment, the only guarantee we have is that it correct for the *current* environment. When bootstrapping a virtual environment, we need to know its layout, so that we can place the files in the correct locations.

The usual solution in situations like this would be to invoke the interpreter we are targeting to get the correct information (eg. path/to/python -m sysconfig), but that is not possible here as the environment does not exist yet -- we are the ones trying to create it.

To solve this issue, I propose the addition of a "virtual" or "venv" install scheme, for virtual environments. The idea is that virtual environments (defined by the presence of pyvenv.cfg, see [3][4]) will always use this scheme, they will use the paths specified by this scheme and sysconfig.get_default_scheme will always return it (_get_preferred_schemes would have no effect here!).
This makes it possible to know the virtual environment layout for another interpreter, via sysconfig.get_paths(scheme='virtual').

I am not cure if this should be adopted in 3.10 or 3.11, as it effectively makes it impossible to reliably construct virtual environments, and requires workarounds such as [5], that pretty much implements this proposal with non-standardized downstream patches.

[1] https://docs.python.org/3/library/sysconfig.html#sysconfig._get_preferred_schemes
[2] https://github.com/pypa/virtualenv/issues/2208
[3] https://docs.python.org/3/library/site.html?highlight=pyvenv.cfg
[4] https://docs.python.org/3/library/venv.html?highlight=pyvenv.cfg
[5] https://github.com/pypa/virtualenv/pull/2209

----------
assignee: FFY00
messages: 403485
nosy: FFY00, gaborjbernat, hroncok, jaraco
priority: normal
severity: normal
status: open
title: Add install scheme for virtual environment
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Oct  8 14:11:18 2021
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 08 Oct 2021 18:11:18 +0000
Subject: [New-bugs-announce] [issue45414] pathlib.Path.parents negative
 indexing is wrong for absolute paths
Message-ID: <1633716678.9.0.917396229112.issue45414@roundup.psfhosted.org>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

At least on PosixPath (not currently able to try on Windows to check WindowsPath, but from a quick code check I think it'll behave the same way), the negative indexing added in #21041 is implemented incorrectly for absolute paths. Passing either -1 or -2 will return a path representing the root, '/' for PosixPath (which should only be returned for -1), and passing an index of -3 or beyond returns the value expected for that index + 1, e.g. -3 gets the result expected for -2, -4 gets the result for -3, etc. And for the negative index that should be equivalent to index 0, you end up with an IndexError.

The underlying problem appears to be that absolute paths (at least, those created from a string) are represented in self._parts with the root '/' included (redundantly, since self._root has it too), so all the actual components of the path are offset by one.

This does not affect slicing (slicing is implemented using range and slice.indices to perform normalization from negative to positive indices, so it never indexes with a negative index).

Example:

>>> from pathlib import Path
>>> p = Path('/1/2/3')
>>> p._parts
['/', '1', '2', '3']
>>> p.parents[:]
(PosixPath('/1/2'), PosixPath('/1'), PosixPath('/'))
>>> p.parents[-1]
PosixPath('/')
>>> p.parents[-1]._parts  # Still behaves normally as self._root is still '/'
[]
>>> p.parents[-2]
PosixPath('/')
>>> p.parents[-2]._parts
['/']
>>> p.parents[-3]
PosixPath('/1')
>>> p.parents[-4]
Traceback (most recent call last):
    ...
IndexError: -4

It looks like the underlying problem is that the negative indexing code doesn't account for the possibility of '/' being in _parts and behaving as a component separate from the directory/files in the path. Frankly, it's a little odd that _parts includes '/' at all (Path has a ._root/.root attribute that stores it too, and even when '/' isn't in the ._parts/.parts, the generated complete path includes it because of ._root), but it looks like the docs guaranteed that behavior in their examples.

It looks like one of two options must be chosen:

1. Fix the negative indexing code to account for absolute paths, and ensure absolute paths store '/' in ._parts consistently (it should not be possible to get two identical Paths, one of which includes '/' in _parts, one of which does not, which is possible with the current negative indexing bug; not sure if there are any documented code paths that might produce this warped sort of object outside of the buggy .parents), or

2. Make no changes to the negative indexing code, but make absolute paths *never* store the root as the first element of _parts (.parts can prepend self._drive/self._root on demand to match documentation). This probably involves more changes (lots of places assume _parts includes the root, e.g. the _PathParents class's own __len__ method raises a ValueError when called on the warped object returned by p.parents[-1], because it adjusts for the root, and the lack of one means it returns a length of -1).

I think #1 is probably the way to go. I believe all that would require is to add:

if idx < 0:
    return self.__getitem__(len(self) + idx)

just before:

return self._pathcls._from_parsed_parts(self._drv, self._root, self._parts[:-idx - 1])

so it never tries to use a negative idx directly (it has to occur after the check for valid index in [-len(self), len(self) so very negative indices don't recurse until they become positive).

This takes advantage of _PathParents's already adjusting the reported length for the presence of drive/root, keeping the code simple; the alternative I came up with that doesn't recurse changes the original return line:

return self._pathcls._from_parsed_parts(self._drv, self._root, self._parts[:-idx - 1])

to:

adjust = idx >= 0 or not (self._drv or self._root)
return self._pathcls._from_parsed_parts(self._drv, self._root, self._parts[:-idx - adjust])

which is frankly terrible, even if it's a little faster.

----------
components: Library (Lib)
messages: 403488
nosy: josh.r
priority: normal
severity: normal
status: open
title: pathlib.Path.parents negative indexing is wrong for absolute paths
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Oct  8 15:33:14 2021
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Oct 2021 19:33:14 +0000
Subject: [New-bugs-announce] [issue45415] Assert oparg < INSTR_OFFSET()
Message-ID: <1633721594.06.0.212064470222.issue45415@roundup.psfhosted.org>


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

encodings.search_function is triggering this assertion at Python/ceval.c#L4055:

       TARGET(JUMP_ABSOLUTE) {
            PREDICTED(JUMP_ABSOLUTE);
            assert(oparg < INSTR_OFFSET());    <<<

It seems to be saying that absolute jumps should only go backwards?

The assertion is triggering reliably in a Windows debug build (including as part of the build process, which means we can't release right now). I don't see anything Windows-specific here though, so I assume it's core and may just be a codepath in encodings that Linux doesn't use?

----------
components: Interpreter Core
messages: 403495
nosy: steve.dower
priority: release blocker
severity: normal
stage: test needed
status: open
title: Assert oparg < INSTR_OFFSET()
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct  8 16:30:58 2021
From: report at bugs.python.org (Simon Willison)
Date: Fri, 08 Oct 2021 20:30:58 +0000
Subject: [New-bugs-announce] [issue45416] "loop argument must agree with
 lock" instantiating asyncio.Condition
Message-ID: <1633725058.57.0.682695156248.issue45416@roundup.psfhosted.org>


New submission from Simon Willison <swillison at gmail.com>:

In Python 3.10 it is not possible to instantiate an asyncio.Condition that wraps an asyncio.Lock without raising a "loop argument must agree with lock" exception.

This code raises that exception:

    asyncio.Condition(asyncio.Lock())

This worked in previous Python versions.

Note that the error only occurs if an event loop is running. Here's a simple script that replicates the problem:

    import asyncio

    # This runs without an exception:
    print(asyncio.Condition(asyncio.Lock()))

    # This does not work:
    async def example():
        print(asyncio.Condition(asyncio.Lock()))

    # This raises "ValueError: loop argument must agree with lock":
    asyncio.run(example())

----------
components: asyncio
messages: 403500
nosy: asvetlov, simonw, yselivanov
priority: normal
severity: normal
status: open
title: "loop argument must agree with lock" instantiating asyncio.Condition
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct  8 19:52:33 2021
From: report at bugs.python.org (Oliver Margetts)
Date: Fri, 08 Oct 2021 23:52:33 +0000
Subject: [New-bugs-announce] [issue45417] Enum creation non-linear in the
 number of values
Message-ID: <1633737153.71.0.819400116811.issue45417@roundup.psfhosted.org>


New submission from Oliver Margetts <oliver.margetts at gmail.com>:

Creating large enums takes a significant amount of time. Moreover this appears to be nonlinear in the number of entries in the enum. Locally, importing a single python file and taking this to the extreme:

 1000 entries - 0.058s
10000 entries - 4.327s

This is partially addressed by https://bugs.python.org/issue38659 and I can confirm that using `@_simple_enum` does not have this problem. But it seems like that API is only intended for internal use and the 'happy path' for user-defined enums is still not good.

Note that it is not simply parsing the file / creating the instances, it is to do with the cardinality. Creating 100 enums with 100 entries each is far faster than a single 10000 entry enum.

----------
files: huge.py
messages: 403512
nosy: olliemath
priority: normal
severity: normal
status: open
title: Enum creation non-linear in the number of values
type: performance
versions: Python 3.10, Python 3.11, Python 3.7
Added file: https://bugs.python.org/file50332/huge.py

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

From report at bugs.python.org  Sat Oct  9 17:37:56 2021
From: report at bugs.python.org (Joseph Perez)
Date: Sat, 09 Oct 2021 21:37:56 +0000
Subject: [New-bugs-announce] [issue45418] types.UnionType is not
 subscriptable
Message-ID: <1633815476.2.0.253081799183.issue45418@roundup.psfhosted.org>


New submission from Joseph Perez <joperez at hotmail.fr>:

`types.UnionType` is not subscriptable, and this is an issue when type manipulations are done.

A common maniputation I've to do is to substitute all the `TypeVar` of a potential generic type by their specialization in the given context.
For example, given a class:
```python
@dataclass
class Foo(Generic[T]):
    bar: list[T]
    baz: T | None
```
in the case of `Foo[int]`, I want to compute the effective type of the fields, which will be `list[int]` and `int | None`.
It could be done pretty easily by a recursive function:
```python
def substitute(tp, type_vars: dict):
    origin, args = get_origin(tp), get_args(tp)
    if isinstance(tp, TypeVar):
        return type_vars.get(tp, tp)
    elif origin is Annotated:
        return Annotated[(substitute(args[0], type_vars), *args[1:])]
    else:
        return origin[tuple(substitute(arg) for arg in args)]  # this line fails for types.UnionType
```

And this is not the only manipulation I've to do on generic types. In fact, all my library (apischema) is broken in Python 3.10 because of `types.UnionType`.
I've to substitute `types.UnionType` by `typing.Union` everywhere to make things work; `types.UnionType` is just not usable for dynamic manipulations.

I've read PEP 604 and it doesn't mention if `types.UnionType` should be subscriptable or not. Is there a reason for not making it subscriptable?

----------
messages: 403554
nosy: joperez
priority: normal
severity: normal
status: open
title: types.UnionType is not subscriptable
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct  9 20:38:04 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 10 Oct 2021 00:38:04 +0000
Subject: [New-bugs-announce] [issue45419] DegenerateFiles.Path mismatch to
 Traversable interface
Message-ID: <1633826284.05.0.820363562312.issue45419@roundup.psfhosted.org>


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

In [pytest-dev/pytest#9174](https://github.com/pytest-dev/pytest/issues/9174), it became clear that the DegenerateFiles object has a couple of interface mismatches to Traversable:

- name is a property
- open accepts a 'mode' and arbitrary args and kwargs.

Because DegenerateFiles is an intentionally broken handle (when a resource provider is unavailable), there's little harm in the interface being broken, and the interface is already gone in Python 3.11, so the urgency of fixing this is small.

----------
messages: 403564
nosy: jaraco
priority: low
severity: normal
status: open
title: DegenerateFiles.Path mismatch to Traversable interface
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct  9 21:08:28 2021
From: report at bugs.python.org (wyz23x2)
Date: Sun, 10 Oct 2021 01:08:28 +0000
Subject: [New-bugs-announce] [issue45420] Python 3.10 final installation
 failure
Message-ID: <1633828108.74.0.92443333438.issue45420@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Hi, I've downloaded Python 3.10 final (64-bit) from python.org on October 6. But when I run the installer with administrator permission, it says "No Python 3.10 installation was detected". Error code: 0x80070643. The stranger thing is when I run "repair" from the 3.10rc2 installer, it's the same message & code; but, if "modify" is run, the window is "A newer version of Python 3.10 is already installed", error code same. Thanks for help.

----------
components: Installation, Windows
files: new_install_log.log
messages: 403566
nosy: paul.moore, steve.dower, tim.golden, wyz23x2, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.10 final installation failure
type: crash
versions: Python 3.10
Added file: https://bugs.python.org/file50335/new_install_log.log

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

From report at bugs.python.org  Sun Oct 10 01:45:37 2021
From: report at bugs.python.org (Alberto Mardegan)
Date: Sun, 10 Oct 2021 05:45:37 +0000
Subject: [New-bugs-announce] [issue45421] Remove dead code from html.parser
Message-ID: <1633844737.55.0.569517591306.issue45421@roundup.psfhosted.org>


New submission from Alberto Mardegan <mardy at users.sourceforge.net>:

There appears to be some dead code in the html.parser module:

https://github.com/python/cpython/blob/main/Lib/html/parser.py#L331-L337

Support for parser errors (with line and offset information) was removed long ago, so this code is useless now. The updatepos() and getpos() methods should also be removed.

----------
components: Library (Lib)
messages: 403571
nosy: mardy
priority: normal
severity: normal
status: open
title: Remove dead code from html.parser
type: enhancement

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

From report at bugs.python.org  Sun Oct 10 06:19:58 2021
From: report at bugs.python.org (=?utf-8?b?Smlhbmtl44CAU0hJ?=)
Date: Sun, 10 Oct 2021 10:19:58 +0000
Subject: [New-bugs-announce] [issue45422] Data 0 cannot be plotted by
 matplotlib.pyplot just because some data is less than 0.
 (ContourSet._get_lowers_and_uppers)
Message-ID: <1633861198.87.0.716585299031.issue45422@roundup.psfhosted.org>


New submission from Jianke?SHI <shi.jianke.xhdre at showadenko.com>:

Data 0 cannot be plotted by matplotlib.pyplot(3.3.4) just because some data is less than 0 (python 3.8.8).

The following is a sample program to confirm the problem.
the left-bottom area in the right figure is not colored and remains transparent just because the data z[2,2] is changed from 0 to -1.7E-13.
(see attached png file.)


I tried to trace the problem and find that the reason seems to be a bug in ContourSet._get_lowers_and_uppers.(Line 1065 in contour.py(3.3.4))

        if self.zmin == lowers[0]:
            # Include minimum values in lowest interval
            lowers = lowers.copy()  # so we don't change self._levels
            if self.logscale:
                lowers[0] = 0.99 * self.zmin
            else:
                lowers[0] -= 1

while lowers[0] is the same as self.zmin, it will be reduced a little before using. However, while lowers[0] is greater than self.zmin ( = -1.7E-13 ), it will not be reduced and remains as it is.
I think the condition should be revised to self.zmin <= lowers[0]
 from self.zmin == lowers[0]. 

(sample program)

import numpy as np
import matplotlib.pyplot as plt
%matplotlib inline

z0 = np.array([[0., 0., 2.], [0., 0., 1.], [2., 1., 0.]])
z1 = np.array([[0., 0., 2.], [0., 0., 1.], [2., 1., -1.7E-13]])

fig = plt.figure(figsize=(2, 4))

ax0 = fig.add_subplot(121)
ax0.contourf(z0, cmap='jet')
ax0.set_aspect('equal')

ax1 = fig.add_subplot(122)
ax1.contourf(z1, cmap='jet')
ax1.set_aspect('equal')

plt.show()

----------
components: Library (Lib)
files: test_contourf_jet4r.png
messages: 403579
nosy: Klam
priority: normal
severity: normal
status: open
title: Data 0 cannot be plotted by matplotlib.pyplot just because some data is less than 0. (ContourSet._get_lowers_and_uppers)
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file50337/test_contourf_jet4r.png

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

From report at bugs.python.org  Sun Oct 10 09:41:48 2021
From: report at bugs.python.org (Thomas Hobson)
Date: Sun, 10 Oct 2021 13:41:48 +0000
Subject: [New-bugs-announce] [issue45423] SSL SNI varies when host contains
 port number
Message-ID: <1633873308.53.0.464980119434.issue45423@roundup.psfhosted.org>


New submission from Thomas Hobson <thomas at hexf.me>:

Not entirely sure if this is intended.

When using urllib.request.urlopen, with a hostname and a varying port the SNI information sent differs.
To my undersnding, the SNI info shouldn't include the port and should only include the actual host.

Attached is an example script demonstrating the issue, where the only difference between the URLs is adding a port number.
The server it points to is configured to only match "ci.hexf.me".

----------
assignee: christian.heimes
components: SSL
files: test.py
messages: 403586
nosy: christian.heimes, hexf
priority: normal
severity: normal
status: open
title: SSL SNI varies when host contains port number
type: behavior
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50338/test.py

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

From report at bugs.python.org  Sun Oct 10 11:26:02 2021
From: report at bugs.python.org (Rahul Lakshmanan)
Date: Sun, 10 Oct 2021 15:26:02 +0000
Subject: [New-bugs-announce] [issue45424] ssl.SSLError: unknown error
 (_ssl.c:4034)
Message-ID: <1633879562.83.0.398124301666.issue45424@roundup.psfhosted.org>


New submission from Rahul Lakshmanan <rahullak at gmail.com>:

I face this error when trying to use a package called streamlit.

Streamlit calls Tornado which calls SSL.

 File "C:\Users\<username>\.conda\envs\stockprediction\lib\ssl.py", line 589, in create_default_context
    context.load_default_certs(purpose)
  File "C:\Users\<username>\.conda\envs\stockprediction\lib\ssl.py", line 490, in load_default_certs
    self._load_windows_store_certs(storename, purpose)
  File "C:\Users\<username>\.conda\envs\stockprediction\lib\ssl.py", line 482, in _load_windows_store_certs
    self.load_verify_locations(cadata=certs)
ssl.SSLError: unknown error (_ssl.c:4034)

This is using Python 3.7.10 (Anaconda) on Windows 10.

Would be really grateful if you could help resolve this issue. 

Note: I am unable to find this specific issue anywhere on Python.org or on OpenSSL github issues page.

----------
assignee: christian.heimes
components: SSL
messages: 403595
nosy: christian.heimes, rahullak, vstinner
priority: normal
severity: normal
status: open
title: ssl.SSLError: unknown error (_ssl.c:4034)
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Sun Oct 10 21:13:57 2021
From: report at bugs.python.org (Zhong Liu)
Date: Mon, 11 Oct 2021 01:13:57 +0000
Subject: [New-bugs-announce] [issue45425] There is an error in the Chinese
 documentation of contextlib.AbstractContextManager
Message-ID: <1633914837.36.0.697960733933.issue45425@roundup.psfhosted.org>


New submission from Zhong Liu <laxtiz at live.com>:

The documentation of contextlib.AbstractContextManager is incorrectly described as the documentation of contextlib.AbstractAsyncContextManager

from 3.6 to 3.10, all is.

https://docs.python.org/zh-cn/3.6/library/contextlib.html#contextlib.AbstractContextManager
https://docs.python.org/zh-cn/3.10/library/contextlib.html#contextlib.AbstractContextManager

----------
assignee: docs at python
components: Documentation
messages: 403614
nosy: docs at python, laxtiz
priority: normal
severity: normal
status: open
title: There is an error in the Chinese documentation of contextlib.AbstractContextManager
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 11 01:08:45 2021
From: report at bugs.python.org (Jimmy Alexander)
Date: Mon, 11 Oct 2021 05:08:45 +0000
Subject: [New-bugs-announce] [issue45426] PANDAS INSTALLATION PIP FAILED ON
 WINDOWS 11
Message-ID: <1633928925.31.0.00114589869577.issue45426@roundup.psfhosted.org>


New submission from Jimmy Alexander <jagonzalezx at gmail.com>:

Generating code
  Finished generating code
  building 'pandas._libs.parsers' extension
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DNPY_NO_DEPRECATED_API=0 -I.\pandas\_libs -Ipandas/_libs/src/klib -Ipandas/_libs/src -IC:\Users\ufx\AppData\Local\Temp\pip-build-env-e6frjkyc\overlay\Lib\site-packages\numpy\core\include -IC:\Users\ufx\AppData\Local\Programs\Python\Python310\include -IC:\Users\ufx\AppData\Local\Programs\Python\Python310\Include -IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include -IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt /Tcpandas/_libs/src/parser/io.c /Fobuild\temp.win-amd64-3.10\Release\pandas/_libs/src/parser/io.obj
  io.c
  pandas/_libs/src/klib\khash.h(705): warning C4090: 'function': different 'const' qualifiers
  pandas/_libs/src/parser/io.c(139): error C2065: 'ssize_t': undeclared identifier
  pandas/_libs/src/parser/io.c(139): error C2146: syntax error: missing ';' before identifier 'rv'
  pandas/_libs/src/parser/io.c(139): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(145): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(145): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
  pandas/_libs/src/parser/io.c(146): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(157): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(158): error C2065: 'rv': undeclared identifier
  error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29910\\bin\\HostX86\\x64\\cl.exe' failed with exit code 2
  ----------------------------------------
  ERROR: Failed building wheel for pandas
Failed to build pandas
ERROR: Could not build wheels for pandas which use PEP 517 and cannot be installed directly

----------
components: Windows
messages: 403618
nosy: jdfoxito, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PANDAS INSTALLATION PIP FAILED ON WINDOWS 11
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 11 02:06:02 2021
From: report at bugs.python.org (David Rajaratnam)
Date: Mon, 11 Oct 2021 06:06:02 +0000
Subject: [New-bugs-announce] [issue45427] importlib.readers.MultiplexedPath
Message-ID: <1633932362.03.0.000713660770349.issue45427@roundup.psfhosted.org>


New submission from David Rajaratnam <daver at gemarex.com.au>:

I'm trying to use `importlib.resources.files()`. However, I cannot work out how to properly use the `importlib.readers.MultiplexedPath()` object that is returned.

As I expect and want, the returned object is referring to a directory, but I cannot seem to simply access the value of that path. 

For a normal `pathlib.Path` object you can get a OS specific path by simply converting to the string representation (eg., 'str(pathlib.Path('/somepath') == '/somepath'). However, for the MutiplexedPath object the __str__() value is the same as the __repr__() (e.g., "MultiplexedPath('/somepath')").

It seems that this is a bug since I would expect MultiplexedPath to behave the same as pathlib.Path in this regard. In the meantime is there a way to actually access this data without stripping the prefix and suffix of this string?

----------
components: Library (Lib)
messages: 403621
nosy: daveraja
priority: normal
severity: normal
status: open
title: importlib.readers.MultiplexedPath
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 11 03:30:08 2021
From: report at bugs.python.org (Graham Inggs)
Date: Mon, 11 Oct 2021 07:30:08 +0000
Subject: [New-bugs-announce] [issue45428] py_compile fails to read filenames
 from stdin
Message-ID: <1633937408.55.0.373736391126.issue45428@roundup.psfhosted.org>


New submission from Graham Inggs <ginggs at debian.org>:

py_compile fails to read a list of filenames to be compiled from standard input.  This is a regression in 3.10.

example

files-to-compile.txt is a text file containing hello.py and goodbye.py on separate lines.  hello.py and goodbye.py must exist.

python3.10 -m py_compile - <files-to-compile.txt
[Errno 2] No such file or directory: 'hello.py\n'

python3.9 -m py_compile - <files-to-compile.txt

python3.9 produces no output, but a __pycache__ directory is created and contains the byte-code files.

----------
components: Library (Lib)
messages: 403624
nosy: ginggs
priority: normal
pull_requests: 27164
severity: normal
status: open
title: py_compile fails to read filenames from stdin
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 11 04:28:27 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2021 08:28:27 +0000
Subject: [New-bugs-announce] [issue45429] [Windows] time.sleep() should use
 CREATE_WAITABLE_TIMER_HIGH_RESOLUTION
Message-ID: <1633940907.8.0.793399065339.issue45429@roundup.psfhosted.org>


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

In bpo-21302, the Windows implementation of time.sleep() was modified to use a waitable timer:

New changeset 58f8adfda3c2b42f654a55500e8e3a6433cb95f2 by Victor Stinner in branch 'main':
bpo-21302: time.sleep() uses waitable timer on Windows (GH-28483)
https://github.com/python/cpython/commit/58f8adfda3c2b42f654a55500e8e3a6433cb95f2

It now calls the functions:

* CreateWaitableTimerW()
* SetWaitableTimer()
* WaitForMultipleObjects()

While SetWaitableTimer() has a resolution of 100 ns, the timer has a resolution of 15.6 ms in practice.

We could use the undocumented CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag with CreateWaitableTimerEx(). See: https://bugs.python.org/issue21302#msg403550

See also:

* https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/
* https://vstinner.readthedocs.io/windows.html#time

----------
components: Library (Lib)
messages: 403631
nosy: vstinner
priority: normal
severity: normal
status: open
title: [Windows] time.sleep() should use CREATE_WAITABLE_TIMER_HIGH_RESOLUTION
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 11 05:11:00 2021
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 11 Oct 2021 09:11:00 +0000
Subject: [New-bugs-announce] [issue45430] PEP 523 no longer works
Message-ID: <1633943460.16.0.196975597767.issue45430@roundup.psfhosted.org>


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

https://github.com/python/cpython/pull/28488 breaks PEP 523 as it bypasses _PyEval_EvalFrame.

The fix is simple, we need to check tstate->interp->eval_frame.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 403637
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: PEP 523 no longer works
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 11 05:50:03 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2021 09:50:03 +0000
Subject: [New-bugs-announce] [issue45431] [C API] Rename CFrame or hide it
 to only export names starting with Py
Message-ID: <1633945803.57.0.940910379519.issue45431@roundup.psfhosted.org>


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

#include <Python.h> should only define names which start with "Py" (Py, _Py, PY, _PY), but it now defines a structure called "CFrame" in Include/cpython/pystate.h.

We should either make the whole PyThreadState structure private (move it to the internal C API), or rename CFrame (to PyCFrame?).

----------
components: C API
messages: 403639
nosy: Mark.Shannon, vstinner
priority: normal
severity: normal
status: open
title: [C API] Rename CFrame or hide it to only export names starting with Py
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 11 11:38:52 2021
From: report at bugs.python.org (Paul)
Date: Mon, 11 Oct 2021 15:38:52 +0000
Subject: [New-bugs-announce] [issue45432] sys.argv is processed strangely
 under Windows
Message-ID: <1633966732.25.0.191303680489.issue45432@roundup.psfhosted.org>


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

here is my test file:
'''
import sys
print(sys.argv)
'''

when I then try 'python test.py ^test' the ^ character is stripped away, this doesn't happen on Linux. This also doesn't happen if I put ^test in quotes (only ") the ' quotes don't work

----------
components: Windows
messages: 403656
nosy: paul.moore, paulhippler21, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: sys.argv is processed strangely under Windows
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 11 14:11:14 2021
From: report at bugs.python.org (Mike Gilbert)
Date: Mon, 11 Oct 2021 18:11:14 +0000
Subject: [New-bugs-announce] [issue45433] libpython should not be linked
 with libcrypt
Message-ID: <1633975874.59.0.522297770504.issue45433@roundup.psfhosted.org>


New submission from Mike Gilbert <floppymaster at gmail.com>:

In https://bugs.python.org/issue44751, crypt.h was removed from Python.h. This would imply that libpython is not meant to expose any crypt-related symbols.

In fact, it looks like libpython does not use crypt() or crypt_r() at all. These are only used by cryptmodule.

In configure.ac, we have this this logic to determine if crypt_r() is available:

```
# We search for both crypt and crypt_r as one or the other may be defined
# This gets us our -lcrypt in LIBS when required on the target platform.
AC_SEARCH_LIBS(crypt, crypt)
AC_SEARCH_LIBS(crypt_r, crypt)

AC_CHECK_FUNC(crypt_r,
  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#define _GNU_SOURCE  /* Required for crypt_r()'s prototype in glibc. */
#include <crypt.h>
]], [[
struct crypt_data d;
char *r = crypt_r("", "", &d);
]])],
    [AC_DEFINE(HAVE_CRYPT_R, 1, [Define if you have the crypt_r() function.])],
    [])
)
```

The AC_SEARCH_LIBS macro adds "-lcrypt" to LIBS, and this gets passed down to the link command for libpython. This is probably not intentional.

The HAVE_CRYPT_R value is used in _cryptmodule.c. setup.py performs its own check for libcrypt when building the module.

I think the value of LIBS should be saved before the AC_SEARCH_LIBS calls and restored after the AC_CHECK_FUNC call. I have tested this locally on Gentoo Linux, and it seems to work fine.

I will work on a pull request.

----------
components: C API
messages: 403663
nosy: floppymaster
priority: normal
severity: normal
status: open
title: libpython should not be linked with libcrypt
type: compile error
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/issue45433>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:08:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2021 20:08:05 +0000
Subject: [New-bugs-announce] [issue45434] [C API] Clean-up the Python.h
 header file
Message-ID: <1633982885.76.0.0750854032549.issue45434@roundup.psfhosted.org>


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

I would like to remove #include <stdlib.h> from Python.h, and make Python.h smaller.

----------
components: C API
messages: 403675
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Clean-up the Python.h header file
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 11 16:25:32 2021
From: report at bugs.python.org (Thomas Grainger)
Date: Mon, 11 Oct 2021 20:25:32 +0000
Subject: [New-bugs-announce] [issue45435] delete misleading faq entry about
 atomic operations
Message-ID: <1633983932.32.0.221950529783.issue45435@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, graingert
priority: normal
severity: normal
status: open
title: delete misleading faq entry about atomic operations

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

From report at bugs.python.org  Mon Oct 11 16:27:07 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2021 20:27:07 +0000
Subject: [New-bugs-announce] [issue45436] test_configure_type() failed on
Message-ID: <1633984027.59.0.32532195896.issue45436@roundup.psfhosted.org>


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

x86 Gentoo Non-Debug with X 3.x:
https://buildbot.python.org/all/#/builders/58/builds/891

test.pythoninfo:

tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.11

2 tests failed:
    test_tk test_ttk_guionly

======================================================================
FAIL: test_configure_type (tkinter.test.test_tkinter.test_widgets.MenuTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/test_tkinter/test_widgets.py", line 1244, in test_configure_type
    self.checkEnumParam(widget, 'type',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
    self.checkInvalidParam(widget, name, '',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
    with self.assertRaises(tkinter.TclError) as cm:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised

======================================================================
FAIL: test_configure_compound (tkinter.test.test_ttk.test_widgets.ButtonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 173, in test_configure_compound
    self.checkEnumParam(widget, 'compound',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
    self.checkInvalidParam(widget, name, '',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
    with self.assertRaises(tkinter.TclError) as cm:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised

======================================================================
FAIL: test_configure_compound (tkinter.test.test_ttk.test_widgets.CheckbuttonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 173, in test_configure_compound
    self.checkEnumParam(widget, 'compound',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
    self.checkInvalidParam(widget, name, '',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
    with self.assertRaises(tkinter.TclError) as cm:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised

======================================================================
FAIL: test_configure_compound (tkinter.test.test_ttk.test_widgets.LabelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 173, in test_configure_compound
    self.checkEnumParam(widget, 'compound',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
    self.checkInvalidParam(widget, name, '',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
    with self.assertRaises(tkinter.TclError) as cm:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised

======================================================================
FAIL: test_configure_compound (tkinter.test.test_ttk.test_widgets.MenubuttonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 173, in test_configure_compound
    self.checkEnumParam(widget, 'compound',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
    self.checkInvalidParam(widget, name, '',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
    with self.assertRaises(tkinter.TclError) as cm:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised

======================================================================
FAIL: test_configure_compound (tkinter.test.test_ttk.test_widgets.RadiobuttonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/test_ttk/test_widgets.py", line 173, in test_configure_compound
    self.checkEnumParam(widget, 'compound',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 151, in checkEnumParam
    self.checkInvalidParam(widget, name, '',
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/tkinter/test/widget_tests.py", line 73, in checkInvalidParam
    with self.assertRaises(tkinter.TclError) as cm:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: TclError not raised

----------
components: Tests, Tkinter
messages: 403678
nosy: gpolo, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: test_configure_type() failed on
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 11 16:27:20 2021
From: report at bugs.python.org (Xin Sheng Zhou)
Date: Mon, 11 Oct 2021 20:27:20 +0000
Subject: [New-bugs-announce] [issue45437] Assignment to a list of dictionary
 wrong
Message-ID: <1633984040.92.0.743378226513.issue45437@roundup.psfhosted.org>


New submission from Xin Sheng Zhou <xinshengzhou at gmail.com>:

>>> details = [{}]*4
>>> details
[{}, {}, {}, {}]
>>> details[1]['A']=5
>>> details
[{'A': 5}, {'A': 5}, {'A': 5}, {'A': 5}]
>>>

----------
messages: 403679
nosy: xinshengzhou
priority: normal
severity: normal
status: open
title: Assignment to a list of dictionary wrong
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 11 18:05:54 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Oct 2021 22:05:54 +0000
Subject: [New-bugs-announce] [issue45438] inspect not capturing type
 annotations created by __class_getitem__
Message-ID: <1633989954.57.0.417241455875.issue45438@roundup.psfhosted.org>


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

In the example below, __annotations__ is correct but not the corresponding Signature object.

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

from typing import List

def f(s: List[float]) -> None: pass

def g(s: list[float]) -> None: pass

>>> inspect.signature(f)
<Signature (s: List[float]) -> None>

>>> inspect.signature(g)
<Signature (s: list) -> None>

g.__annotations__
{'s': list[float], 'return': None}

----------
components: Library (Lib)
messages: 403692
nosy: gvanrossum, levkivskyi, rhettinger
priority: normal
severity: normal
status: open
title: inspect not capturing type annotations created by __class_getitem__
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 11 18:18:05 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2021 22:18:05 +0000
Subject: [New-bugs-announce] [issue45439] [C API] Move usage of
 tp_vectorcall_offset from public headers to the internal C API
Message-ID: <1633990685.32.0.752281797082.issue45439@roundup.psfhosted.org>


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

The public C API should avoid accessing directly PyTypeObject members: see bpo-40170.

I propose to move static inline functions to the internal C API, and only expose opaque function calls to the public C API.

----------
components: C API
messages: 403695
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Move usage of tp_vectorcall_offset from public headers to the internal C API
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 11 19:51:20 2021
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2021 23:51:20 +0000
Subject: [New-bugs-announce] [issue45440] [C API] Py_IS_INFINITY() macro
 doesn't work in the limited C API if isinf() is not defined
Message-ID: <1633996280.11.0.993737910951.issue45440@roundup.psfhosted.org>


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

If the HAVE_DECL_ISINF macro is not defined in pyconfig.h, the Py_IS_INFINITY macro is defined as:

#define Py_IS_INFINITY(X) \
    ((X) && (Py_FORCE_DOUBLE(X)*0.5 == Py_FORCE_DOUBLE(X)))

Problem: Py_FORCE_DOUBLE() is excluded from the limited C API (and the stable ABI).

I see different options:

* Implement Py_IS_INFINITY() as an opaque function if the HAVE_DECL_ISINF macro is not defined. I did something similar in Py_INCREF() to support the limited C API with a debug build of Python: call _Py_IncRef() opaque function.

* Make Py_FORCE_DOUBLE() private and add it to the limited C API as an implementation detail.

* Add Py_FORCE_DOUBLE() macro to the limited C API: the current implementation is fragile, it depends on how Python.h is included. Also, I dislike macros in the limited C API.

I would prefer to *remove* Py_FORCE_DOUBLE() to all APIs, than adding it to the limited C API.

----------
components: C API
messages: 403704
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Py_IS_INFINITY() macro doesn't work in the limited C API if isinf() is not defined
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 03:01:15 2021
From: report at bugs.python.org (jiahua wang)
Date: Tue, 12 Oct 2021 07:01:15 +0000
Subject: [New-bugs-announce] [issue45441] Some links in the document is
 changed
Message-ID: <1634022075.47.0.874322884428.issue45441@roundup.psfhosted.org>


Change by jiahua wang <wjh180909 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: 180909, docs at python
priority: normal
pull_requests: 27191
severity: normal
status: open
title: Some links in the document is changed
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 06:39:52 2021
From: report at bugs.python.org (Shivnaren Srinivasan)
Date: Tue, 12 Oct 2021 10:39:52 +0000
Subject: [New-bugs-announce] [issue45442] Update `Virtual Environment`
 tutorial
Message-ID: <1634035192.74.0.26138584631.issue45442@roundup.psfhosted.org>


New submission from Shivnaren Srinivasan <shivnaren at gmail.com>:

Priority: Low

The Virtual Environment tutorial page (https://docs.python.org/3/tutorial/venv.html) doesn't specify how we can revert, or deactivate the `venv`.

This is quite a popular question on SO:
https://stackoverflow.com/questions/990754/how-to-leave-exit-deactivate-a-python-virtualenv

``deactivate`` worked for me?this could be added to the docs?

Happy to submit a PR.

----------
assignee: docs at python
components: Documentation
messages: 403722
nosy: docs at python, shivnaren
priority: normal
severity: normal
status: open
title: Update `Virtual Environment` tutorial
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/issue45442>
_______________________________________

From report at bugs.python.org  Tue Oct 12 06:48:59 2021
From: report at bugs.python.org (Zohim Chandani)
Date: Tue, 12 Oct 2021 10:48:59 +0000
Subject: [New-bugs-announce] [issue45443] 'ThreadPoolExecutor' object has no
 attribute 'map'
Message-ID: <1634035739.42.0.184025452389.issue45443@roundup.psfhosted.org>


New submission from Zohim Chandani <zohim.chandani at gmail.com>:

import concurrent.futures 
import time 


start = time.perf_counter()

def do_something(seconds):
    print(f'sleeping for {seconds}s ... ')
    time.sleep(seconds)
    return f'done sleeping {seconds} '


with concurrent.futures.ThreadPoolExecutor() as executor: 

    secs = [5,4,3,2,1]
    
    results = executor.map(do_something, secs)

    for result in results: 
        print(result)




finish = time.perf_counter()

print(f'finished in {round(finish-start, 2)} seconds')



The above code yields an attribute error whereas it used to execute perfectly before. Did the method get removed?

----------
messages: 403723
nosy: zohim
priority: normal
severity: normal
status: open
title: 'ThreadPoolExecutor' object has no attribute 'map'
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 12 09:37:47 2021
From: report at bugs.python.org (tongxiaoge)
Date: Tue, 12 Oct 2021 13:37:47 +0000
Subject: [New-bugs-announce] [issue45444] test.test_concurrent_futures fail
 in x86_ 64 architecture
Message-ID: <1634045867.87.0.955416673386.issue45444@roundup.psfhosted.org>


New submission from tongxiaoge <shixuantong at huawei.com>:

When I was building Python3,the test case test. Test_ concurrent_ Futures.threadpoolwaittests always fails. The error message is as follows:

[ 1680s] test_zero_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 2.12s ok
[ 1680s] test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 83.82s FAIL
[ 1680s] test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 80.08s FAIL
[ 1680s] test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 77.34s FAIL
[ 1680s] test_error_at_task_pickle (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 0.12s ok



[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155, in test_crash_at_task_unpickle
[ 1680s]     self._check_crash(BrokenProcessPool, id, CrashAtUnpickle())
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159, in test_crash_during_func_exec_on_worker
[ 1680s]     self._check_crash(BrokenProcessPool, _crash)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172, in test_crash_during_result_pickle_on_worker
[ 1680s]     self._check_crash(BrokenProcessPool, _return_instance, CrashAtPickle)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155, in test_crash_at_task_unpickle
[ 1680s]     self._check_crash(BrokenProcessPool, id, CrashAtUnpickle())
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159, in test_crash_during_func_exec_on_worker
[ 1680s]     self._check_crash(BrokenProcessPool, _crash)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172, in test_crash_during_result_pickle_on_worker
[ 1680s]     self._check_crash(BrokenProcessPool, _return_instance, CrashAtPickle)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155, in test_crash_at_task_unpickle
[ 1680s]     self._check_crash(BrokenProcessPool, id, CrashAtUnpickle())
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159, in test_crash_during_func_exec_on_worker
[ 1680s]     self._check_crash(BrokenProcessPool, _crash)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ======================================================================
[ 1680s] FAIL: test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 1680s]     res.result(timeout=self.TIMEOUT)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 1680s]     raise TimeoutError()
[ 1680s] concurrent.futures._base.TimeoutError
[ 1680s]
[ 1680s] During handling of the above exception, another exception occurred:
[ 1680s]
[ 1680s] Traceback (most recent call last):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172, in test_crash_during_result_pickle_on_worker
[ 1680s]     self._check_crash(BrokenProcessPool, _return_instance, CrashAtPickle)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 1680s]     self._fail_on_deadlock(executor)
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 1680s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 1680s] AssertionError: Executor deadlock:
[ 1680s]
[ 1680s] Thread 0x00007f6389d6f700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Thread 0x00007f638a570700 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 1680s]
[ 1680s] Current thread 0x00007f63982a1740 (most recent call first):
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 202 in _runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest_mp.py", line 83 in run_tests_worker
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 678 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 1680s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 1680s]
[ 1680s]
[ 1680s] ----------------------------------------------------------------------
[ 1680s] Ran 226 tests in 1091.207s
[ 1680s]
[ 1680s] FAILED (failures=9, skipped=6)
[ 1680s] test test_concurrent_futures failed
[ 1710s] 0:18:48 load avg: 4.43 running: test_capi (18 min 45 sec), test_faulthandler (18 min 35 sec)
[ 1740s] 0:19:18 load avg: 4.34 running: test_capi (19 min 15 sec), test_faulthandler (19 min 5 sec)
[ 1770s] 0:19:48 load avg: 4.44 running: test_capi (19 min 45 sec), test_faulthandler (19 min 35 sec)
[ 1800s] 0:20:18 load avg: 4.38 running: test_capi (20 min 15 sec), test_faulthandler (20 min 5 sec)
[ 1830s] 0:20:48 load avg: 4.33 running: test_capi (20 min 45 sec), test_faulthandler (20 min 35 sec)
[ 1830s] 0:20:48 load avg: 4.33 [422/423/1] test_faulthandler passed (20 min 34 sec) -- running: test_capi (20 min 45 sec)
[ 1860s] 0:21:18 load avg: 3.86 running: test_capi (21 min 15 sec)
[ 1890s] 0:21:48 load avg: 3.51 running: test_capi (21 min 45 sec)
[ 1920s] 0:22:18 load avg: 3.33 running: test_capi (22 min 15 sec)
[ 1950s] 0:22:48 load avg: 3.66 running: test_capi (22 min 45 sec)
[ 1980s] 0:23:18 load avg: 3.44 running: test_capi (23 min 15 sec)
[ 2010s] 0:23:48 load avg: 3.42 running: test_capi (23 min 45 sec)
[ 2040s] 0:24:18 load avg: 3.45 running: test_capi (24 min 15 sec)
[ 2070s] 0:24:48 load avg: 3.43 running: test_capi (24 min 45 sec)
[ 2100s] 0:25:18 load avg: 3.85 running: test_capi (25 min 15 sec)
[ 2130s] 0:25:48 load avg: 4.27 running: test_capi (25 min 45 sec)
[ 2160s] 0:26:18 load avg: 4.32 running: test_capi (26 min 15 sec)
[ 2190s] 0:26:48 load avg: 4.17 running: test_capi (26 min 45 sec)
[ 2220s] 0:27:18 load avg: 4.10 running: test_capi (27 min 15 sec)
[ 2238s] 0:27:36 load avg: 3.72 [423/423/1] test_capi passed (27 min 32 sec)
[ 2238s]
[ 2238s] == Tests result: FAILURE ==
[ 2238s]
[ 2238s] 402 tests OK.
[ 2238s]
[ 2238s] 10 slowest tests:
[ 2238s] - test_capi: 27 min 32 sec
[ 2238s] - test_faulthandler: 20 min 34 sec
[ 2238s] - test_concurrent_futures: 18 min 11 sec
[ 2238s] - test_io: 3 min 11 sec
[ 2238s] - test_subprocess: 2 min 26 sec
[ 2238s] - test_peg_generator: 2 min 19 sec
[ 2238s] - test_audit: 2 min 16 sec
[ 2238s] - test_multiprocessing_spawn: 2 min 9 sec
[ 2238s] - test_regrtest: 1 min 33 sec
[ 2238s] - test_threading: 1 min 26 sec
[ 2238s]
[ 2238s] 1 test failed:
[ 2238s]     test_concurrent_futures
[ 2238s]
[ 2238s] 20 tests skipped:
[ 2238s]     test_curses test_devpoll test_ioctl test_kqueue test_msilib
[ 2238s]     test_ossaudiodev test_smtpnet test_socketserver test_startfile
[ 2238s]     test_timeout test_tix test_tk test_ttk_guionly test_urllib2net
[ 2238s]     test_urllibnet test_winconsoleio test_winreg test_winsound
[ 2238s]     test_xmlrpc_net test_zipfile64
[ 2238s] 0:27:36 load avg: 3.72
[ 2238s] 0:27:36 load avg: 3.72 Re-running failed tests in verbose mode
[ 2238s] 0:27:36 load avg: 3.72 Re-running test_concurrent_futures in verbose mode (matching: test_crash_at_task_unpickle, test_crash_during_func_exec_on_worker, test_crash_during_result_pickle_on_worker, test_crash_at_task_unpickle, test_crash_during_func_exec_on_worker, test_crash_during_result_pickle_on_worker, test_crash_at_task_unpickle, test_crash_during_func_exec_on_worker, test_crash_during_result_pickle_on_worker)
[ 2318s] test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ...
[ 2318s] Traceback:
[ 2318s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2318s]
[ 2318s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2318s]
[ 2318s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2318s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2318s]
[ 2318s] 79.95s FAIL
[ 2398s] test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ...
[ 2398s] Traceback:
[ 2398s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2398s]
[ 2398s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2398s]
[ 2398s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2398s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2398s]
[ 2398s] 80.54s FAIL
[ 2477s] test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ...
[ 2477s] Traceback:
[ 2477s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2477s]
[ 2477s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2477s]
[ 2477s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2477s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2477s]
[ 2477s] 78.53s FAIL
[ 2554s] test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ...
[ 2554s] Traceback:
[ 2554s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2554s]
[ 2554s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2554s]
[ 2554s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2554s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2554s]
[ 2554s] 76.82s FAIL
[ 2631s] test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ...
[ 2631s] Traceback:
[ 2631s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2631s]
[ 2631s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2631s]
[ 2631s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2631s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2631s]
[ 2631s] 77.49s FAIL
[ 2706s] test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ...
[ 2706s] Traceback:
[ 2706s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2706s]
[ 2706s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2706s]
[ 2706s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2706s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2706s]
[ 2706s] 75.22s FAIL
[ 2782s] test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ...
[ 2782s] Traceback:
[ 2782s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2782s]
[ 2782s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2782s]
[ 2782s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2782s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2782s]
[ 2782s] 75.96s FAIL
[ 2858s] test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ...
[ 2858s] Traceback:
[ 2858s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2858s]
[ 2858s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2858s]
[ 2858s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2858s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2858s]
[ 2858s] 76.14s FAIL
[ 2935s] test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ...
[ 2935s] Traceback:
[ 2935s]  Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s] 76.73s FAIL
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155, in test_crash_at_task_unpickle
[ 2935s]     self._check_crash(BrokenProcessPool, id, CrashAtUnpickle())
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159, in test_crash_during_func_exec_on_worker
[ 2935s]     self._check_crash(BrokenProcessPool, _crash)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172, in test_crash_during_result_pickle_on_worker
[ 2935s]     self._check_crash(BrokenProcessPool, _return_instance, CrashAtPickle)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155, in test_crash_at_task_unpickle
[ 2935s]     self._check_crash(BrokenProcessPool, id, CrashAtUnpickle())
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159, in test_crash_during_func_exec_on_worker
[ 2935s]     self._check_crash(BrokenProcessPool, _crash)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172, in test_crash_during_result_pickle_on_worker
[ 2935s]     self._check_crash(BrokenProcessPool, _return_instance, CrashAtPickle)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_at_task_unpickle (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155, in test_crash_at_task_unpickle
[ 2935s]     self._check_crash(BrokenProcessPool, id, CrashAtUnpickle())
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1155 in test_crash_at_task_unpickle
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_during_func_exec_on_worker (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159, in test_crash_during_func_exec_on_worker
[ 2935s]     self._check_crash(BrokenProcessPool, _crash)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1159 in test_crash_during_func_exec_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ======================================================================
[ 2935s] FAIL: test_crash_during_result_pickle_on_worker (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest)
[ 2935s] ----------------------------------------------------------------------
[ 2935s] test test_concurrent_futures failed
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1133, in _check_crash
[ 2935s]     res.result(timeout=self.TIMEOUT)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/_base.py", line 447, in result
[ 2935s]     raise TimeoutError()
[ 2935s] concurrent.futures._base.TimeoutError
[ 2935s]
[ 2935s] During handling of the above exception, another exception occurred:
[ 2935s]
[ 2935s] Traceback (most recent call last):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172, in test_crash_during_result_pickle_on_worker
[ 2935s]     self._check_crash(BrokenProcessPool, _return_instance, CrashAtPickle)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137, in _check_crash
[ 2935s]     self._fail_on_deadlock(executor)
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1114, in _fail_on_deadlock
[ 2935s]     self.fail(f"Executor deadlock:\n\n{tb}")
[ 2935s] AssertionError: Executor deadlock:
[ 2935s]
[ 2935s] Thread 0x00007fbd57fff700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 320 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/queues.py", line 233 in _feed
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 946 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Thread 0x00007fbd74ff9700 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/selectors.py", line 416 in select
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/multiprocessing/connection.py", line 936 in wait
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 377 in wait_result_broken_or_wakeup
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/concurrent/futures/process.py", line 317 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 1009 in _bootstrap_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/threading.py", line 966 in _bootstrap
[ 2935s]
[ 2935s] Current thread 0x00007fbdae8ec740 (most recent call first):
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1105 in _fail_on_deadlock
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1137 in _check_crash
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/test_concurrent_futures.py", line 1172 in test_crash_during_result_pickle_on_worker
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 549 in _callTestMethod
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 591 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/case.py", line 650 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 122 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/suite.py", line 84 in __call__
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/unittest/runner.py", line 176 in run
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 990 in _run_suite
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/support/__init__.py", line 1115 in run_unittest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 261 in _test_module
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 297 in _runtest_inner2
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 335 in _runtest_inner
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 215 in _runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/runtest.py", line 245 in runtest
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 337 in rerun_failed_tests
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 715 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 658 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/libregrtest/main.py", line 736 in main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 43 in _main
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/test/regrtest.py", line 47 in <module>
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 86 in _run_code
[ 2935s]   File "/home/abuild/rpmbuild/BUILD/Python-3.10.0/Lib/runpy.py", line 196 in _run_module_as_main
[ 2935s]
[ 2935s]
[ 2935s] ----------------------------------------------------------------------
[ 2935s] Ran 9 tests in 697.425s
[ 2935s]
[ 2935s] FAILED (failures=9)
[ 2935s] 1 test failed again:
[ 2935s]     test_concurrent_futures


This test case is successful on the aarch64 architecture. What might cause this?

(I'm very sorry. I don't know who to copy to. I choose  these developers who  recently submitted code modified file Lib/test/test_concurrent_futures.py.)

----------
components: Library (Lib), Tests
messages: 403732
nosy: Asheesh.Laroia, serhiy.storchaka, shihai1991, sxt1001
priority: normal
severity: normal
status: open
title: test.test_concurrent_futures fail in x86_ 64 architecture
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 12 09:39:46 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 12 Oct 2021 13:39:46 +0000
Subject: [New-bugs-announce] [issue45445] Fail if an invalid -X option is
 provided
Message-ID: <1634045986.72.0.556620578821.issue45445@roundup.psfhosted.org>


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

We found that using -X ---- can be very confusing and annoying when you make typos, so I think having errors if you pass some unknown stuff will be outweighing any downside of making this more strict.

----------
messages: 403733
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Fail if an invalid -X option is provided

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

From report at bugs.python.org  Tue Oct 12 11:23:21 2021
From: report at bugs.python.org (Nium)
Date: Tue, 12 Oct 2021 15:23:21 +0000
Subject: [New-bugs-announce] [issue45446] Add a way to hide fields in
 dataclasses
Message-ID: <1634052201.09.0.291070468305.issue45446@roundup.psfhosted.org>


Change by Nium <formigacomcaimbra at gmail.com>:


----------
nosy: formigacomcaimbra
priority: normal
severity: normal
status: open
title: Add a way to hide fields in dataclasses
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 11:24:36 2021
From: report at bugs.python.org (Alex Waygood)
Date: Tue, 12 Oct 2021 15:24:36 +0000
Subject: [New-bugs-announce] [issue45447] Support syntax highlighting for
 .pyi stub files
Message-ID: <1634052276.56.0.989526823091.issue45447@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

IDLE currently does not do any syntax highlighting if you use it to open a .pyi stub file, even though everything in a .pyi file is a valid Python expression. It would be great if syntax highlighting for .pyi files could be supported.

----------
assignee: terry.reedy
components: IDLE
messages: 403738
nosy: AlexWaygood, terry.reedy
priority: normal
severity: normal
status: open
title: Support syntax highlighting for .pyi stub files
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 11:38:42 2021
From: report at bugs.python.org (Zayden Micheal James)
Date: Tue, 12 Oct 2021 15:38:42 +0000
Subject: [New-bugs-announce] [issue45448] PIP package installation failure
 for multiple packages
Message-ID: <1634053122.93.0.794234678092.issue45448@roundup.psfhosted.org>


New submission from Zayden Micheal James <zayvelleman at gmail.com>:

When I try to install numpy using python version 3.10, pip version 21.2.4
it gives me a PEP517 error, with a bunch of other exceptions.

When I try to install tensorflow using python version 3.10, pip version 21.2.4 it gives me an error saying that there is no such package.

I've tried multiple pip and python combo's for installation... Aswell as inside and outside a virtual enviroment.

----------
components: Installation
messages: 403740
nosy: zayvelleman
priority: normal
severity: normal
status: open
title: PIP package installation failure for multiple packages
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 12 13:11:41 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Tue, 12 Oct 2021 17:11:41 +0000
Subject: [New-bugs-announce] [issue45449] Document that collections.abc
 types are subscriptable
Message-ID: <1634058701.61.0.841344967504.issue45449@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

Since 3.9, the types in collections.abc are subscriptable and can be used as type hints, but this is not documented.
We should write something similar to what's on the typing module documentation for the deprecated types.

----------
assignee: docs at python
components: Documentation
messages: 403744
nosy: FFY00, docs at python, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Document that collections.abc types are subscriptable
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Oct 12 13:20:57 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 12 Oct 2021 17:20:57 +0000
Subject: [New-bugs-announce] [issue45450] Improve syntax error for
 parenthesized arguments
Message-ID: <1634059257.61.0.643840687035.issue45450@roundup.psfhosted.org>


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

There is a non-trivial ammount of users that try to parenthesize lambda parameters:

>>> lambda (x,y,z): x+y+z
  File "<stdin>", line 1
    lambda (x,y,z): x+y+z
           ^
SyntaxError: invalid syntax

We should improve the error message in this case

----------
messages: 403747
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for parenthesized arguments

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

From report at bugs.python.org  Tue Oct 12 21:04:56 2021
From: report at bugs.python.org (primexx)
Date: Wed, 13 Oct 2021 01:04:56 +0000
Subject: [New-bugs-announce] [issue45451] IDLE Shell GUI - remove window
 border
Message-ID: <1634087096.76.0.0471723883661.issue45451@roundup.psfhosted.org>


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

Python 3.10 bundled IDLE with a small change in the interactive interpreter shell.

Previously, the line indicators ">>>" were in-line with the command line, and a long/multi line command would have the same indentation as the indicator which was not ideal.

that has been changed in 3.10 so that the line indicators are in a separate area as the actual commands so actual commands are always indented consistently. this is good.

however, there is now a thick window border separating the line indicator and the main window. this is jarring and creates a visual separation that disassociates the line indicator from the line itself.

i have on several occasions sat there waiting for something to finish only to notice that it has already finished but i missed seeing the next line indicator to the left.

the window border creates two separate spaces and is distracting.

an improvement would be to instead of the window border, eliminate it and shade the left side with a very light colour (probably even lighter than my photoshop in the attached image).

actually, I suggest that the best solution is to remove the window border and leave the entire thing contiguously white, with no shading, similar to what it looked like previously. except that it now has correct indentation. I think this is the most visually cohesive and easy to use.

Attached is an image to illustrate. Again, I suggest the "not shaded" version is the best.

----------
assignee: terry.reedy
components: IDLE
files: idle310.PNG
messages: 403774
nosy: primexx, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE Shell GUI - remove window border
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file50352/idle310.PNG

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

From report at bugs.python.org  Tue Oct 12 21:45:22 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 13 Oct 2021 01:45:22 +0000
Subject: [New-bugs-announce] [issue45452] Support crash tolerance for gdbm
 module
Message-ID: <1634089522.9.0.931859161119.issue45452@roundup.psfhosted.org>


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

>From gdbm 1.21, gdbm supports the crash tolerance feature.
We may need to provide APIs for those versions.

https://www.gnu.org.ua/software/gdbm/manual/Crash-Tolerance.html

Following features will be provided if the user using gdbm >= 1.21
- Need to provide `GDBM_NUMSYNC` as `s`.
- Need to provide API for gdbm_failure_atomic()
- Need to provide API for gdbm_latest_snapshot()

----------
assignee: corona10
components: Extension Modules
messages: 403776
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: Support crash tolerance for gdbm module
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 21:52:49 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2021 01:52:49 +0000
Subject: [New-bugs-announce] [issue45453] test_embed: random crash on AMD64
 Fedora Rawhide Clang 3.x
Message-ID: <1634089969.63.0.707166222279.issue45453@roundup.psfhosted.org>


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

test_embed does crash randomly on AMD64 Fedora Rawhide Clang 3.x:

* https://buildbot.python.org/all/#/builders/188/builds/880
* https://buildbot.python.org/all/#/builders/188/builds/879

So far, I failed to reproduce the issue.

----------
components: Tests
messages: 403779
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_embed: random crash on AMD64 Fedora Rawhide Clang 3.x
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 22:09:30 2021
From: report at bugs.python.org (Chris Meyer)
Date: Wed, 13 Oct 2021 02:09:30 +0000
Subject: [New-bugs-announce] [issue45454] Unable to explicitly subclass
 protocol when subclass has mixin requiring init
Message-ID: <1634090970.26.0.320360946482.issue45454@roundup.psfhosted.org>


New submission from Chris Meyer <cmeyer1969 at gmail.com>:

If I make a explicit subclass of a protocol that also inherits from a mixin and calls super() in order to initialize the mixin, I get the "Protocols cannot be instantiated" exception.

This case arises when having a hierarchy of both protocols and concrete classes that implement the protocols.

A simple example is:

import typing


class P(typing.Protocol):
    def m1(self) -> None: ...

class M:
    def __init__(self) -> None:
        super().__init__()
        self.o = True

class C(M, P):
    def __init__(self) -> None:
        super().__init__()
        self.op = True

    def m1(self) -> None:
        pass

c = C()

I can resolve this in particular cases by not invoking super in the mixin or putting a special no-super class in the hierarchy. However, that is not a general solution and once the class hierarchy gets more complicated, it fails to work.

Am I missing any known solution to this issue?

----------
components: Library (Lib)
messages: 403782
nosy: cmeyer
priority: normal
severity: normal
status: open
title: Unable to explicitly subclass protocol when subclass has mixin requiring init
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 12 22:49:58 2021
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 13 Oct 2021 02:49:58 +0000
Subject: [New-bugs-announce] [issue45455] Fill func.__doc__ lazily
Message-ID: <1634093398.63.0.682415750411.issue45455@roundup.psfhosted.org>


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

Move setting `func.__doc__` from PyFunction_New() to __doc__ descriptor, for faster function creation.

This issue is spin-off of bpo-36521.

----------
components: Interpreter Core
messages: 403786
nosy: methane
priority: normal
severity: normal
status: open
title: Fill func.__doc__ lazily
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 12 23:58:17 2021
From: report at bugs.python.org (Evgeniy Ivanov)
Date: Wed, 13 Oct 2021 03:58:17 +0000
Subject: [New-bugs-announce] [issue45456] operator 'pass' in 'if-else'
 linear expression
Message-ID: <1634097497.58.0.0510721088772.issue45456@roundup.psfhosted.org>


New submission from Evgeniy Ivanov <atxn at yandex.ru>:

Why operator 'pass' not implement to 'if-else' linear expression?
Construction '<func/operation> if <expression> else pass' throws SyntaxError in Python 3.9

----------
messages: 403793
nosy: evgnor86
priority: normal
severity: normal
status: open
title: operator 'pass' in 'if-else' linear expression
type: compile error
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 13 03:01:17 2021
From: report at bugs.python.org (Lincoln Puzey)
Date: Wed, 13 Oct 2021 07:01:17 +0000
Subject: [New-bugs-announce] [issue45457] Documentation for
 ssl.load_default_certs is outdated
Message-ID: <1634108477.44.0.93503538382.issue45457@roundup.psfhosted.org>


New submission from Lincoln Puzey <lincolnp at lastyard.com>:

The behavior of `ssl.load_default_certs()` was changed in https://bugs.python.org/issue22449

The new behavior is that `ssl.set_default_verify_paths()` is now called on all systems.

The documentation still says that `ssl.set_default_verify_paths()` is only called on systems OTHER than Windows.

----------
assignee: christian.heimes
components: SSL
messages: 403806
nosy: LincolnPuzeyLastYard, christian.heimes
priority: normal
severity: normal
status: open
title: Documentation for ssl.load_default_certs is outdated

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

From report at bugs.python.org  Wed Oct 13 05:10:37 2021
From: report at bugs.python.org (Owen)
Date: Wed, 13 Oct 2021 09:10:37 +0000
Subject: [New-bugs-announce] [issue45458] "\W" pattern with re.ASCII flag is
 not equivalent to "[^a-zA-Z0-9_]"
Message-ID: <1634116237.24.0.751734837982.issue45458@roundup.psfhosted.org>


New submission from Owen <owentrigueros at gmail.com>:

"\W" regex pattern, when used with `re.ASCII`, is expected to have the same behavior as "[^a-zA-Z0-9_]" (see [1]).

For example, the following `sub()` call

```
>>> re.sub('\W', '', '? a', re.ASCII)
'?a'
```

should return the same as this one:

```
>>> re.sub('[^a-zA-Z0-9_]', '', '? a', re.ASCII)
'a'
```

But it does not.

[1] https://docs.python.org/3/library/re.html#regular-expression-syntax

----------
components: Regular Expressions
messages: 403810
nosy: ezio.melotti, mrabarnett, owentrigueros
priority: normal
severity: normal
status: open
title: "\W" pattern with re.ASCII flag is not equivalent to "[^a-zA-Z0-9_]"
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 13 05:55:13 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Oct 2021 09:55:13 +0000
Subject: [New-bugs-announce] [issue45459] Limited API support for Py_buffer
Message-ID: <1634118913.79.0.141868262007.issue45459@roundup.psfhosted.org>


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

Currently all APIs related to Py_buffer are excluded from the limited API. It's neither possible to use Py_buffer from a C extension with limited API nor is it possible to define heap types with buffer support using the stable ABI.

The lack of Py_buffer support prevents prominent projects like NumPy or Pillow to use the limited API and produce abi3 binary wheel. To be fair it's not the only reason why these projects have not adopted the stable abi3 yet. Still Py_buffer is a necessary but not sufficient condition. Stable abi3 support would enable NumPy stack to build binary wheels that work with any Python version >= 3.11, < 4.0.

The limited API excludes any C API that references Py_buffer:

- 8 PyBuffer_*() functions
- 21 PyBUF_* constants
- PyMemoryView_FromBuffer()
- PyObject_GetBuffer
- Py_bf_getbuffer / Py_bf_releasebuffer type slots for PyBufferProcs

It should not be terribly complicated to add Py_buffer to the stable API. All it takes are an opaque struct definition of Py_buffer, an allocate function, a free function and a bunch of getters and setters. The hard part is to figure out which getters and setters are needed and how many struct members must be exposed by getters and setters. I recommend to get feedback from NumPy, Pillow, and Cython devs first.


Prototype
---------

typedef struct bufferinfo Py_buffer;

/* allocate a new Py_buffer object on the heap and initialize all members to NULL / 0 */
Py_buffer*
PyBuffer_New()
{
    Py_buffer *view = PyMem_Calloc(1, sizeof(Py_buffer));
    if (view == NULL) {
        PyErr_NoMemory();
    }
    return view;
}

/* convenience function */
Py_buffer*
PyBuffer_NewEx(PyObject *obj, void *buf,  Py_ssize_t len, Py_ssize_t itemsize,
               int readonly, int ndim, char *format, Py_ssize_t *shape, Py_ssize_t *strides,
               Py_ssize_t *suboffsets, void *internal)
{
    ...
}

/* release and free buffer */
void
PyBuffer_Free(Py_buffer *view)
{
    if (view != NULL) {
        PyBuffer_Release(view);
        PyMem_Free(view);
    }
}

----------
components: C API
messages: 403813
nosy: christian.heimes, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: Limited API support for Py_buffer
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 13 10:02:39 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 13 Oct 2021 14:02:39 +0000
Subject: [New-bugs-announce] [issue45460]
 distutils.sysconfig.get_python_lib() does not respect sysconfig/distutils
 install schemes
Message-ID: <1634133759.79.0.719278605469.issue45460@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

In https://github.com/python/cpython/pull/24549 (Load install schemes from sysconfig) we have assumed that distutils will simply read all information from sysconfig, so distributors could patch the install schemes in there and distutils (whether the one in the standard library or a third party fork).

However, in https://github.com/pypa/pip/issues/10151#issuecomment-942162384 we have figured out that distutils.sysconfig.get_python_lib() does not respect the schemes from sysconfig at all, instead, it creates the paths from scratch.

This might be too late for Python 3.10, but in Python 3.11 I'd like distutils.sysconfig.get_python_lib() to return paths defined by sysconfig install schemes. That way, we can more easily move that from the standard library to a third-party project with an independent delivery mechanism.

----------
components: Distutils
messages: 403834
nosy: FFY00, dstufft, eric.araujo, frenzy, hroncok, jaraco, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: distutils.sysconfig.get_python_lib() does not respect sysconfig/distutils install schemes
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 13 10:31:37 2021
From: report at bugs.python.org (Anatoly Myachev)
Date: Wed, 13 Oct 2021 14:31:37 +0000
Subject: [New-bugs-announce] [issue45461] UnicodeDecodeError:
 'unicodeescape' codec can't decode byte 0x5c in position 8191: \ at end of
 string
Message-ID: <1634135497.37.0.760320895517.issue45461@roundup.psfhosted.org>


New submission from Anatoly Myachev <anatoliimyachev at mail.ru>:

Expected behavior - if `read()` function works correctly, then `readline()` should also works.

Reproducer in file - just run: `python test.py`.

Traceback (most recent call last):
  File "test.py", line 11, in <module>
    f.readline()
  File "C:\Users\amyachev\Miniconda3\envs\modin\lib\encodings\unicode_escape.py", line 26, in decode
    return codecs.unicode_escape_decode(input, self.errors)[0]
UnicodeDecodeError: 'unicodeescape' codec can't decode byte 0x5c in position 8191: \ at end of string

----------
components: Unicode
files: test.py
messages: 403837
nosy: anmyachev, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: UnicodeDecodeError: 'unicodeescape' codec can't decode byte 0x5c in position 8191: \ at end of string
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50354/test.py

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

From report at bugs.python.org  Wed Oct 13 12:38:53 2021
From: report at bugs.python.org (Jonas H.)
Date: Wed, 13 Oct 2021 16:38:53 +0000
Subject: [New-bugs-announce] [issue45462] Speed up re.match with
 pre-compiled patterns
Message-ID: <1634143133.69.0.265087114017.issue45462@roundup.psfhosted.org>


New submission from Jonas H. <jonas at lophus.org>:

re.match(p, ...) with a pre-compiled pattern p = re.compile(...) can be much slower than calling p.match(...). Probably mostly in cases with "easy" patterns and/or short strings.

The culprit is that re.match -> re._compile can spend a lot of time looking up p its internal _cache, where it will never find p:

def _compile(pattern, flags):
    ...
    try:
        return _cache[type(pattern), pattern, flags]
    except KeyError:
        pass
    if isinstance(pattern, Pattern):
        ...
        return pattern
    ...
        _cache[type(pattern), pattern, flags] = p
    ...

_compile will always return before the _cache is set if given a Pattern object.

By simply reordering the isinstance(..., Pattern) check we can safe a lot of time.

I've seen speedups in the range of 2x-5x on some of my data. As an example:

Raw speed of re.compile(p, ...).match():
    time ./python.exe -c 'import re'\n'pat = re.compile(".").match'\n'for _ in range(1_000_000): pat("asdf")'
    Executed in  190.59 millis

Speed with this optimization:
    time ./python.exe -c 'import re'\n'pat = re.compile(".")'\n'for _ in range(1_000_000): re.match(pat, "asdf")'
    Executed in  291.39 millis

Speed without this optimization:
    time ./python.exe -c 'import re'\n'pat = re.compile(".")'\n'for _ in range(1_000_000): re.match(pat, "asdf")'
    Executed in  554.42 millis

----------
components: Regular Expressions
messages: 403851
nosy: ezio.melotti, jonash, mrabarnett
priority: normal
severity: normal
status: open
title: Speed up re.match with pre-compiled patterns
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 13 13:54:03 2021
From: report at bugs.python.org (Luca)
Date: Wed, 13 Oct 2021 17:54:03 +0000
Subject: [New-bugs-announce] [issue45463] Documentation inconsistency on the
 number of identifiers allowed in global stmt
Message-ID: <1634147643.19.0.48482298028.issue45463@roundup.psfhosted.org>


New submission from Luca <luca at chiodini.org>:

The global statement allows specifying a list of identifiers, as correctly reported in the "Simple statements" chapter: https://docs.python.org/3/reference/simple_stmts.html#the-global-statement.

Inconsistently, however, the "Execution model" chapter describes the global statement as if it only allowed one single name.

This can be addressed by pluralizing the word "name" in the appropriate places in the "Execution model" chapter.

----------
assignee: docs at python
components: Documentation
messages: 403864
nosy: docs at python, lucach
priority: normal
pull_requests: 27227
severity: normal
status: open
title: Documentation inconsistency on the number of identifiers allowed in global stmt

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

From report at bugs.python.org  Wed Oct 13 16:05:16 2021
From: report at bugs.python.org (=?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=)
Date: Wed, 13 Oct 2021 20:05:16 +0000
Subject: [New-bugs-announce] [issue45464] TypeError when inheriting from
 both OSError and AttributeError
Message-ID: <1634155516.92.0.207915157302.issue45464@roundup.psfhosted.org>


New submission from Marek Marczykowski-G?recki <marmarek at mimuw.edu.pl>:

In Python 3.10 it is no longer possible to create an exception type that inherits from both OSError and AttributeError. This has worked in Python 3.9.
I don't see anything in changelog/release notes that would suggest it being intentional.

Behavior in Python 3.9:

Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(OSError, AttributeError): pass
... 
>>> C
<class '__main__.C'>


Behavior in Python 3.10:

Python 3.10.0 (default, Oct  4 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(OSError, AttributeError): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: multiple bases have instance lay-out conflict


My (very) wild guess is this being related to https://bugs.python.org/issue38530

----------
components: Interpreter Core
messages: 403870
nosy: marmarek
priority: normal
severity: normal
status: open
title: TypeError when inheriting from both OSError and AttributeError
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 13 18:39:47 2021
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Wed, 13 Oct 2021 22:39:47 +0000
Subject: [New-bugs-announce] [issue45465] logging messages are needlessly
 reformatted for every handler
Message-ID: <1634164787.38.0.59547649385.issue45465@roundup.psfhosted.org>


New submission from ????? ???????? <dpb at corrigendum.ru>:

Consider this code:

```
import logging

class MyLogRecord(logging.LogRecord):
    def getMessage(self):
        print("Help! I am being formatted!")
        return super().getMessage()

logging.setLogRecordFactory(MyLogRecord)

logger = logging.getLogger("test")
logger.addHandler(logging.StreamHandler())
logger.addHandler(logging.StreamHandler())

logger.error("%d", 123)
```

Its output is:

```
Help! I am being formatted!
123
Help! I am being formatted!
123
```

In other words, the record's `getMessage` method is called once for every handler. That seems quite unnecessary, especially since the formatted message is saved in the `message` field of the record by `Formatter.format`. `Formatter` could check whether the message has already been formatted, and if so, use the saved message.

----------
components: Library (Lib)
messages: 403879
nosy: SpecLad
priority: normal
severity: normal
status: open
title: logging messages are needlessly reformatted for every handler
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 14 02:15:12 2021
From: report at bugs.python.org (Tom Pohl)
Date: Thu, 14 Oct 2021 06:15:12 +0000
Subject: [New-bugs-announce] [issue45466] Simple curl/wget-like download
 functionality in urllib (like http offers server)
Message-ID: <1634192112.29.0.508125660114.issue45466@roundup.psfhosted.org>


New submission from Tom Pohl <thomas.pohl at gmail.com>:

In the context of building Docker images, it is often required to download stuff. If curl/wget are available, great, but often slim images don't offer that.

The urllib could provide a very simple download functionality (like http offers a simple server):

    from urllib.request import urlopen
    data = urlopen('https://.../install-poetry.py').read()
    # print or save data

If there's some interest, I could open a PR.

----------
components: Library (Lib)
messages: 403888
nosy: tom.pohl
priority: normal
severity: normal
status: open
title: Simple curl/wget-like download functionality in urllib (like http offers server)
type: enhancement

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

From report at bugs.python.org  Thu Oct 14 06:29:46 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Oct 2021 10:29:46 +0000
Subject: [New-bugs-announce] [issue45467] Fix incremental decoder and stream
 reader in the "raw-unicode-escape" codec
Message-ID: <1634207386.82.0.577344433134.issue45467@roundup.psfhosted.org>


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

Similar to 45461, but with "raw-unicode-escape".

When an incremental decoder gets a part of escape sequence (\uXXXX or \UXXXXXXXX) it raises an exception or return a bare "\" if it was the only part instead of keeping it until getting the rest. It is exposed in text files (io.TextIOWrapper) when reads from the underlying binary stream splits an escape sequence between blocks. There is similar issue with stream readers (codecs.StreamReader).

----------
components: Unicode
messages: 403893
nosy: ezio.melotti, lemburg, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Fix incremental decoder and stream reader in the "raw-unicode-escape" codec
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Oct 14 07:51:17 2021
From: report at bugs.python.org (Gabriele N Tornetta)
Date: Thu, 14 Oct 2021 11:51:17 +0000
Subject: [New-bugs-announce] [issue45468] Add support for preloading a
 Python script
Message-ID: <1634212277.88.0.777172112966.issue45468@roundup.psfhosted.org>


New submission from Gabriele N Tornetta <phoenix1987 at gmail.com>:

I would like to propose adding support for preloading a Python script before executing a Python application.


Potential design:

A new environment variable (e.g. PY_PRELOAD, an allusion to LD_PRELOAD, or PYTHONPRELOAD to be more aligned with the naming pattern of existing variables) is used to specify the path of the script to execute. The script is then executed just before the import of the site module. This is similar to what PYTHONSTARTUP does, except that it works in all cases, not just when launching the REPL.


Rationale:

There are examples of tools that require performing some operations (e.g. monkey-patching) before starting the actual Python application. Currently, this could be achieved in the following rather contrived way:

- prepare an ad-hoc sitecustomize.py file
- add its path to PYTHONPATH
- run the Python application with the computed PYTHONPATH

The ad-hoc sitecustomize.py requires the following steps

- run the custom initialisation code
- remove the path of the custom sitecustomize.py script from sys.path
- unload the sitecustomize module
- try importing sitecustomize to force-load any original sitecustomize scripts that would have run otherwise

The new environment variable makes the whole process a lot easier by allowing tools to just set a single environment variable to achieve the same result.

----------
components: Interpreter Core
messages: 403898
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: Add support for preloading a Python script
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 14 08:20:21 2021
From: report at bugs.python.org (Vincent Liang)
Date: Thu, 14 Oct 2021 12:20:21 +0000
Subject: [New-bugs-announce] [issue45469] lambda issue in for-loop
Message-ID: <1634214021.97.0.77826806934.issue45469@roundup.psfhosted.org>


New submission from Vincent Liang <shenheng80 at qq.com>:

Strange behavior is found when lambda is used inside for-loop.

code:(same as attached file)

# begin of CODE
def aa(x):
    print("aa")
def bb(x):
    print("bb")

namefun = [
    ("a", aa),
    ("b", bb),
]
name2fun = {}
for name, fun in namefun:
    name2fun[name] = lambda x: fun(x)
# issue happened when calling lambda
name2fun["a"](1)
name2fun["b"](1)
# end of CODE

output:
bb
bb

expected output:
aa
bb

----------
components: Interpreter Core
files: test8.py
messages: 403899
nosy: vincent7f
priority: normal
severity: normal
status: open
title: lambda issue in for-loop
type: behavior
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50357/test8.py

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

From report at bugs.python.org  Thu Oct 14 12:42:55 2021
From: report at bugs.python.org (Stefan)
Date: Thu, 14 Oct 2021 16:42:55 +0000
Subject: [New-bugs-announce] [issue45470] possible bug in
 datetime.timestamp()
Message-ID: <1634229775.61.0.860983412697.issue45470@roundup.psfhosted.org>


New submission from Stefan <stefan at sriha.net>:

I noticed that there is a difference between intervals when computed from timedeltas vs timestamps. Is this a bug? Thanks!

In [2]: import datetime as datet
In [3]: d0 = datet.datetime(2016,3,27)
In [4]: d1 = datet.datetime(2016,3,28)
In [5]: (d1-d0).total_seconds()/3600
Out[5]: 24.0
In [6]: (d1.timestamp()-d0.timestamp())/3600
Out[6]: 23.0

----------
messages: 403917
nosy: stef
priority: normal
severity: normal
status: open
title: possible bug in datetime.timestamp()
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 14 14:22:57 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Oct 2021 18:22:57 +0000
Subject: [New-bugs-announce] [issue45471] _Py_path_config.stdlib_dir should
 not be set in Py_SetPythonHome().
Message-ID: <1634235777.13.0.980768160554.issue45471@roundup.psfhosted.org>


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

(This follows bpo-45211.)

In gh-28586 I added the code in Py_SetPythonHome() to set _Py_path_config.stdlib_dir to the provided directory.  However, this is the wrong value.  Furthermore, the relationship between _Py_path_config.home and _Py_path_config.stdlib_dir is meant to managed in Modules/getpath.c (and PC/getpathp.c).  So the code setting _Py_path_config.stdlib_dir in Py_SetPythonHome() should be dropped.

----------
assignee: eric.snow
components: Interpreter Core
messages: 403926
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: _Py_path_config.stdlib_dir should not be set in Py_SetPythonHome().
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 14 14:40:52 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Oct 2021 18:40:52 +0000
Subject: [New-bugs-announce] [issue45472] Add public C API for partial
 "unicode-escape" and "raw-unicode-escape" decoding
Message-ID: <1634236852.53.0.0839626073282.issue45472@roundup.psfhosted.org>


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

The proposed PR adds C API functions PyUnicode_DecodeUnicodeEscapeStateful() and PyUnicode_DecodeRawUnicodeEscapeStateful() for partially decoding with "unicode-escape" and "raw-unicode-escape" encodings. It were the only multibyte text codecs which did not provide such interface.

They are neccessary for correct implementation of increment decoders and stream  readers (see issue45461 and issue45467).

----------
components: Unicode
messages: 403932
nosy: ezio.melotti, lemburg, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add public C API for partial "unicode-escape" and "raw-unicode-escape" decoding
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 14 15:11:28 2021
From: report at bugs.python.org (Aaron Koch)
Date: Thu, 14 Oct 2021 19:11:28 +0000
Subject: [New-bugs-announce] [issue45473] Enum add "from_name" and
 "from_value" class methods
Message-ID: <1634238688.3.0.350018662934.issue45473@roundup.psfhosted.org>


New submission from Aaron Koch <aaronkoch99 at yahoo.com>:

Documentation: https://docs.python.org/3/library/enum.html#creating-an-enum

Current behavior:

SomeEnum[name] is used to construct an enum by name
SomeEnum(value) is used to construct an enum by value

Problem:

As a user of enums, it is difficult to remember the mapping between parenthesis/square brackets and construct from name/construct from value.

Suggestion: Add two class methods to Enum

@classmethod
def from_name(cls, name):
    return cls[name]

@classmethod
def from_value(cls, value):
    return cls(value)


Benefits:

This is an additive change only, it doesn't change any behavior of the Enum class, so there are no backwards compatibility issues.  Adding these aliases to the Enum class would allow readers and writers of enums to interact with them more fluently and with less trips to the documentation.  Using these aliases would make it easier to write the code you intended and to spot bugs that might arise from the incorrect use of from_name or from_value.

----------
messages: 403936
nosy: aekoch
priority: normal
severity: normal
status: open
title: Enum add "from_name" and "from_value" class methods
type: enhancement

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

From report at bugs.python.org  Thu Oct 14 16:09:23 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2021 20:09:23 +0000
Subject: [New-bugs-announce] [issue45474] [C API] marshal.h must not use
 FILE* type in the limited C API
Message-ID: <1634242163.67.0.843815202649.issue45474@roundup.psfhosted.org>


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

Include/marshal.h defines 2 functions with FILE* argument in the limited C API, whereas the PEP 384 disallows that:

"In addition, functions expecting FILE* are not part of the ABI, to avoid depending on a specific version of the Microsoft C runtime DLL on Windows."
https://www.python.org/dev/peps/pep-0384/

PyAPI_FUNC(void) PyMarshal_WriteLongToFile(long, FILE *, int);
PyAPI_FUNC(void) PyMarshal_WriteObjectToFile(PyObject *, FILE *, int);

I propose to exclude these functions from the limited C API.

Hopefully, they are not part of the documented stable ABI.

----------
components: C API
messages: 403941
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] marshal.h must not use FILE* type in the limited C API
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 14 17:12:01 2021
From: report at bugs.python.org (minstrelofc)
Date: Thu, 14 Oct 2021 21:12:01 +0000
Subject: [New-bugs-announce] [issue45475] gzip fails to read a gzipped file
 (ValueError: readline of closed file)
Message-ID: <1634245921.58.0.043840382812.issue45475@roundup.psfhosted.org>


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

Attempting to iterate over an opened gzip file raises a ValueError: readline of closed file

Behavior in Python 3.9.7:
Python 3.9.7 (default, Oct 13 2021, 09:08:19) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> ll = [l for l in gzip.GzipFile(filename='data/UTF-8-test_for_gzip.txt.gz')]
>>> len(ll)
300


Behavior in Python 3.10.0 (and 3.11.0a1 is the same):
Python 3.10.0 (default, Oct 13 2021, 08:53:15) [GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> ll = [l for l in gzip.GzipFile(filename='data/UTF-8-test_for_gzip.txt.gz')]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
ValueError: readline of closed file


This only happens when iterating directly over the GzipFile object. Using a with: statement has the correct behaviour in both 3.10 and 3.11:
>>> with gzip.GzipFile(filename='UTF-8-test_for_gzip.txt.gz') as input_file:
...     len(list(input_file))
... 
300

----------
files: UTF-8-test_for_gzip.txt.gz
messages: 403948
nosy: minstrelofc
priority: normal
severity: normal
status: open
title: gzip fails to read a gzipped file (ValueError: readline of closed file)
type: behavior
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50358/UTF-8-test_for_gzip.txt.gz

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

From report at bugs.python.org  Thu Oct 14 17:17:31 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2021 21:17:31 +0000
Subject: [New-bugs-announce] [issue45476] [C API] Convert "AS" functions,
 like PyFloat_AS_DOUBLE(), to static inline functions
Message-ID: <1634246251.33.0.982878943146.issue45476@roundup.psfhosted.org>


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

The Python C API provides "AS" functions to convert an object to another type, like PyFloat_AS_DOUBLE(). These macros can be abused to be used as l-value: "PyFloat_AS_DOUBLE(obj) = new_value;". It prevents to change the PyFloat implementation and makes life harder for Python implementations other than CPython.

I propose to convert these macros to static inline functions to disallow using them as l-value.

I made a similar change for Py_REFCNT(), Py_TYPE() and Py_SIZE(). For these functions, I added "SET" variants: Py_SET_REFCNT(), Py_SET_TYPE(), Py_SET_SIZE(). Here, I don't think that the l-value case is legit, and so I don't see the need to add a way to *set* a value.

For example, I don't think that PyFloat_SET_DOUBLE(obj, value) would make sense. A Python float object is supposed to be immutable.

----------
components: C API
messages: 403950
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Convert "AS" functions, like PyFloat_AS_DOUBLE(), to static inline functions
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 14 17:19:53 2021
From: report at bugs.python.org (Sourish Basu)
Date: Thu, 14 Oct 2021 21:19:53 +0000
Subject: [New-bugs-announce] [issue45477] configure script cannot detect
 float word ordering on linux
Message-ID: <1634246393.25.0.871269149475.issue45477@roundup.psfhosted.org>


New submission from Sourish Basu <sourish.basu at gmail.com>:

I am trying to compile Python 3.10.0 on a Red Hat linux system with intel C/C++ compilers. This is my configure command:

```
./configure --with-computed-gotos --without-gcc --with-ensurepip=install --enable-optimizations --with-libm=-limf --with-cxx-main=icpc --with-threads --enable-ipv6 --with-signal-module CC=icc CXX=icpc LD=xild AR=xiar LIBS='-lpthread -limf -lirc' CFLAGS='-O3 -fPIC -fp-model strict -fp-model source -axCORE-AVX512,CORE-AVX2 -xAVX -ipo -prec-div -prec-sqrt' LDFLAGS='-ipo' CPP='icc -E'
```

The failure comes as follows:

```
checking for --with-libm=STRING... set LIBM="-limf"
checking for --with-libc=STRING... default LIBC=""
checking for x64 gcc inline assembler... yes
checking whether float word ordering is bigendian... unknown
configure: error:

Unknown float word ordering. You need to manually preset
ax_cv_c_float_words_bigendian=no (or yes) according to your system.
```

I saw issue 38527 was fixed in 3.10. Perhaps fixing it on Solaris broke it on some other platforms?

----------
components: Installation
messages: 403951
nosy: sourish.basu
priority: normal
severity: normal
status: open
title: configure script cannot detect float word ordering on linux
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 14 21:56:59 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 15 Oct 2021 01:56:59 +0000
Subject: [New-bugs-announce] [issue45478] Send a patch to libexpat to solve
 _POSIX_C_SOURCE issue.
Message-ID: <1634263019.88.0.531243767636.issue45478@roundup.psfhosted.org>


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

Yesterday, I left an issue to libexpat project about what we solved yesterday to follow Christian suggestion.

https://github.com/libexpat/libexpat/issues/513

The maintainer suggests sending a patch with reordering all headers files related to expat_config.h.
I am now preparing the patch.

I would like to know if there are more issues that we have to solve except header ordering that I don't know yet :)

----------
assignee: corona10
components: Build
messages: 403968
nosy: christian.heimes, corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Send a patch to libexpat to solve _POSIX_C_SOURCE issue.
type: enhancement

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

From report at bugs.python.org  Thu Oct 14 23:58:47 2021
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Oct 2021 03:58:47 +0000
Subject: [New-bugs-announce] [issue45479] clean up Py_UniversalNewlineFgets
Message-ID: <1634270327.41.0.602561770606.issue45479@roundup.psfhosted.org>


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

Py_UniversalNewlineFgets has a bunch of dead code and general gunk that should be removed.

----------
assignee: benjamin.peterson
components: IO
messages: 403970
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: clean up Py_UniversalNewlineFgets
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 15 03:17:44 2021
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 15 Oct 2021 07:17:44 +0000
Subject: [New-bugs-announce] [issue45480] Missing link(s) to the "Python
 Module Index" page
Message-ID: <1634282264.33.0.0720790922492.issue45480@roundup.psfhosted.org>


New submission from Mark Summerfield <mark at qtrac.eu>:

I mostly use the Python 3.8 docs since that's the Python I use.
However, when I tried using the 3.9 and 3.10 docs I found that the top of each page has a long search bar (presumably for mobile devices?) but _no_ link to the python module index. I find this last page the most important page for looking things up, so I really hope the 'modules' link is restored.

----------
assignee: docs at python
components: Documentation
messages: 403977
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: Missing link(s) to the "Python Module Index" page
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct 15 03:31:36 2021
From: report at bugs.python.org (EricLin)
Date: Fri, 15 Oct 2021 07:31:36 +0000
Subject: [New-bugs-announce] [issue45481] gc is disabled without explict
 calling gc.disable()
Message-ID: <1634283096.3.0.498579479489.issue45481@roundup.psfhosted.org>


New submission from EricLin <linxiaojun1 at huawei.com>:

First, I would like to clarify that this is a Python 2.7.5 issue. I know python2 is no longer maintained, but I still wish to look for some help here.

We have observed a long running Python 2.7.5 process leaking memory. I tried to inject some code into the process using gdb, to see what's happening inside.
The gdb command looks like:
gdb -p $pid -batch -eval-command='call PyGILState_Ensure()' -eval-command='call PyRun_SimpleString("exec(open(\"/path/to/code\").read())")' -eval-command='call PyGILState_Release($1)'

I printed gc.get_objects() information into a file and took 2 snapshots, but failed to find obvious object size increase. But after calling gc.collect() in the injected code, a dramatic memory decrease is observed. So I tried to print the return value following:

gc.isenabled()
gc.get_count()
gc.get_threshold()

which gives me:

False
(56107, 0, 0)
(700, 10, 10)

This obviously shows that gc is disabled, but I'm sure non of our code does it explicitly. And the same code is running on hundreds of servers but only one has this problem.

Does anyone have any idea what might be the cause, or what to check to find the root cause?

----------
components: Library (Lib)
messages: 403980
nosy: linxiaojun
priority: normal
severity: normal
status: open
title: gc is disabled without explict calling gc.disable()
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct 15 04:00:51 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2021 08:00:51 +0000
Subject: [New-bugs-announce] [issue45482] [C API] Add
 PySimpleNamespace_New() function
Message-ID: <1634284851.38.0.689716122011.issue45482@roundup.psfhosted.org>


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

Python has a types.SimpleNamespace type which is convenient to cheap a "simple namespace". I propose to make its C API public (but exclude it from the limited C API): add PySimpleNamespace_New() function.

It's currently used in:

* Modules/timemodule.c: time.get_clock_info(name)
* Python/sysmodule.c: sys.implementation

It's also used in:

* Python/import.c: _PyImport_BootstrapImp()
* Modules/_testmultiphase.c: createfunc_nonmodule() used as the Py_mod_create slot

----------
components: C API
messages: 403984
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Add PySimpleNamespace_New() function
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 15 08:59:43 2021
From: report at bugs.python.org (GalaxySnail)
Date: Fri, 15 Oct 2021 12:59:43 +0000
Subject: [New-bugs-announce] [issue45483] pure Python class that has been
 registered as a `collections.abc.Sequence` can't be recgnized by the match
 statement without the `_abc` module
Message-ID: <1634302783.77.0.196268254173.issue45483@roundup.psfhosted.org>


New submission from GalaxySnail <ylc991 at 163.com>:

Pure Python class that has been registered as a `collections.abc.Sequence` can't be recgnized by the match statement without the `_abc` module.

For example:

```
>>> from test.support.import_helper import import_fresh_module

>>> collections_abc_with_c_abc = import_fresh_module(
...     "collections.abc", fresh=["_collections_abc", "abc", "_abc"])

>>> class MyList:
...     def __init__(self, iterable):
...         self.list = list(iterable)
...     def __len__(self):
...         return len(self.list)
...     def __getitem__(self, item):
...         return self.list[item]
...
>>> collections_abc_with_c_abc.Sequence.register(MyList)
<class '__main__.MyList'>
>>> match MyList(range(3, 10)):
...     case [x, *_]:
...         print(x)
...     case _:
...         print("not a sequence")
...
3

>>> collections_abc_with_py_abc = import_fresh_module(
...     "collections.abc", fresh=["_collections_abc", "abc"], blocked=["_abc"])
>>> class MyList:
...     def __init__(self, iterable):
...         self.list = list(iterable)
...     def __len__(self):
...         return len(self.list)
...     def __getitem__(self, item):
...         return self.list[item]
...
>>> collections_abc_with_py_abc.Sequence.register(MyList)
<class '__main__.MyList'>
>>> match MyList(range(3, 10)):
...     case [x, *_]:
...         print(x)
...     case _:
...         print("not a sequence")
...
not a sequence
```

It seems to be caused by https://github.com/python/cpython/commit/069e81ab3da46c441335ca762c4333b7bd91861d , only `tp_flags` are checked in the `MATCH_SEQUENCE` opcode. `Mapping` has the same problem.

----------
messages: 404011
nosy: GalaxySnail
priority: normal
severity: normal
status: open
title: pure Python class that has been registered as a `collections.abc.Sequence` can't be recgnized by the match statement without the `_abc` module
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Oct 15 09:27:03 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2021 13:27:03 +0000
Subject: [New-bugs-announce] [issue45484] test_pickle segfault on s390x
 RHEL7 LTO 3.x
Message-ID: <1634304423.18.0.10367404371.issue45484@roundup.psfhosted.org>


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

s390x RHEL7 LTO 3.x:
https://buildbot.python.org/all/#/builders/402/builds/979

--------------------
0:02:00 load avg: 5.14 [193/427/2] test_pickletools crashed (Exit code -11) -- running: test_unparse (30.6 sec), test_concurrent_futures (1 min 56 sec), test_multiprocessing_spawn (43.2 sec)
Fatal Python error: Segmentation fault

Current thread 0x000003ffb8e77700 (most recent call first):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3304 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  (...)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  ...

Extension modules: _testcapi, _testbuffer (total: 2)
--------------------

and

--------------------
test_instance_dispatch_table (test.test_pickle.CDispatchTableTests) ... ok
test_appends_on_non_lists (test.test_pickle.CDumpPickle_LoadPickle) ... ok
test_attribute_name_interning (test.test_pickle.CDumpPickle_LoadPickle) ... ok
Fatal Python error: Segmentation fault

Current thread 0x000003ff80377700 (most recent call first):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  (...)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z.lto/build/Lib/test/pickletester.py", line 3305 in __getattr__
  ...

Extension modules: _testcapi, _testbuffer (total: 2)
--------------------

----------
components: Tests
messages: 404014
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_pickle segfault on s390x RHEL7 LTO 3.x
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 15 09:59:25 2021
From: report at bugs.python.org (Freek de Kruijf)
Date: Fri, 15 Oct 2021 13:59:25 +0000
Subject: [New-bugs-announce] [issue45485] datetime.strptime issues message
 attribute of type 'NoneType' is not callableTraceback
Message-ID: <1634306365.71.0.931982823754.issue45485@roundup.psfhosted.org>


New submission from Freek de Kruijf <f.de.kruijf at gmail.com>:

In a piece of code I have
pT = datetime.strptime(a[0],"%Y-%m-%dT%H:%M:%S.%f")
When I check type(a[0]) I got type(a[0]): <class 'str'> not <type 'str'>
In this case I get: message attribute of type 'NoneType' is not callableTraceback
When I use str(a[0]) instead of a[0], the issue is gone.
a[0] behaves elsewhere as a string without the surrounding str().
This piece of code is rather local in a larger program.

----------
components: Interpreter Core
messages: 404018
nosy: f.de.kruijf
priority: normal
severity: normal
status: open
title: datetime.strptime issues message attribute of type 'NoneType' is not callableTraceback
type: behavior

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

From report at bugs.python.org  Fri Oct 15 10:58:34 2021
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Oct 2021 14:58:34 +0000
Subject: [New-bugs-announce] [issue45486] Stop using internal APIs in
 _xxsubinterpretersmodule.c.
Message-ID: <1634309914.57.0.687775238283.issue45486@roundup.psfhosted.org>


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

By design, _xxsubinterpretersmodule is not supposed to be a builtin module.  As a regular extension module it should only use public (or private-but-not-internal) APIs.  In fact, I was careful to not use any internal APIs in the implementation.  However, some have crept in.  The usage of internal API should be replaced with public (or private) API.  If necessary, new API should be added.

----------
messages: 404027
nosy: eric.snow, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Stop using internal APIs in _xxsubinterpretersmodule.c.
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 15 11:41:08 2021
From: report at bugs.python.org (Richard)
Date: Fri, 15 Oct 2021 15:41:08 +0000
Subject: [New-bugs-announce] [issue45487] SSLEOFError regression with
 certain servers in Python 3.10
Message-ID: <1634312468.77.0.966089091529.issue45487@roundup.psfhosted.org>


New submission from Richard <nyuszika7h at gmail.com>:

Starting in Python 3.10, TLS connections to certain servers (e.g. websocket-cs.vudu.com:443) are failing when it worked fine on Python 3.9 and earlier on the same system.


Minimal working example:

```
#!/usr/bin/env python3

import socket
import ssl

HOST = 'websocket-cs.vudu.com'
PORT = 443

sock = socket.create_connection((HOST, PORT))
ctx = ssl.create_default_context()
ssock = ctx.wrap_socket(sock, server_hostname=HOST)
print("Connection successful")
```


Output:
```
? python3.9 ssl_eof_test.py
Connection successful

? python3.10 ssl_eof_test.py
Traceback (most recent call last):
  File "/home/nyuszika7h/ssl_eof_test.py", line 11, in <module>
    ssock = ctx.wrap_socket(sock, server_hostname=HOST)
  File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/ssl.py", line 512, in wrap_socket
    return self.sslsocket_class._create(
  File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/ssl.py", line 1070, in _create
    self.do_handshake()
  File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/ssl.py", line 1341, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:997)

? python3.11 ssl_eof_test.py
Traceback (most recent call last):
  File "/home/nyuszika7h/ssl_eof_test.py", line 11, in <module>
    ssock = ctx.wrap_socket(sock, server_hostname=HOST)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/ssl.py", line 517, in wrap_socket
    return self.sslsocket_class._create(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/ssl.py", line 1075, in _create
    self.do_handshake()
    ^^^^^^^^^^^^^^^^^^^
  File "/home/nyuszika7h/.pyenv/versions/3.11-dev/lib/python3.11/ssl.py", line 1346, in do_handshake
    self._sslobj.do_handshake()
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:998)
```


System information:

```
? uname -a
Linux cadoth 5.10.0-8-amd64 #1 SMP Debian 5.10.46-5 (2021-09-23) x86_64 GNU/Linux

? lsb_release -d
Description:    Debian GNU/Linux 11 (bullseye)

? openssl version
OpenSSL 1.1.1k  25 Mar 2021

? python3.9 -VV
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110]

? python3.10 -VV
Python 3.10.0 (default, Oct  5 2021, 00:24:29) [GCC 10.2.1 20210110]

? python3.11 -VV
Python 3.11.0a1+ (heads/main:547d26aa08, Oct 15 2021, 17:35:52) [GCC 10.2.1 20210110]

? python3.9 -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.1.1k  25 Mar 2021

? python3.10 -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.1.1k  25 Mar 2021

? python3.11 -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.1.1k  25 Mar 2021
```

----------
assignee: christian.heimes
components: SSL
messages: 404033
nosy: christian.heimes, nyuszika7h
priority: normal
severity: normal
status: open
title: SSLEOFError regression with certain servers in Python 3.10
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Oct 15 12:25:23 2021
From: report at bugs.python.org (The Guy)
Date: Fri, 15 Oct 2021 16:25:23 +0000
Subject: [New-bugs-announce] [issue45488] Powershell Commands no Longer
 Recognised
Message-ID: <1634315123.49.0.821466530777.issue45488@roundup.psfhosted.org>


New submission from The Guy <julienbloxerk at gmail.com>:

I am using pyinstaller to port my python programs into windows executables so that I can distribute them among my friends, and I recently assigned python to my windows PATH (I'm still not 100% sure what that means so idk if im even saying that right) and now a large amount of my computers basic powershell commands are no longer recognized; trying to use the cmd cmdlet i am only met with the "not recognized as the name of a cmdlet, function, or operable program" error. I've checked the internet pretty extensively and I haven't found anything that works, if you know what's going on or have any ideas on how to fix it, any help would be greatly appreciated. 
P.S. I am an amateur programmer and I just started dipping my toes into python, so I apologize if I don't give enough/correct information, I am still very new to this and am happy to answer questions as needed. Also sorry if this is the wrong place to ask about these kinds of issues, idk where else to ask. (pls be nice im new)

----------
assignee: docs at python
components: Documentation, Windows
messages: 404036
nosy: docs at python, julienbloxerk, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Powershell Commands no Longer Recognised
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 15 12:37:31 2021
From: report at bugs.python.org (Bobbey Reese)
Date: Fri, 15 Oct 2021 16:37:31 +0000
Subject: [New-bugs-announce] [issue45489] ForwardRef does not support |
 operator
Message-ID: <1634315851.69.0.0714715298786.issue45489@roundup.psfhosted.org>


New submission from Bobbey Reese <bobbeyreese at gmail.com>:

Not positive this is a bug, but it seems like ForwardRef should support the pipe (|) operator for indicating Unions in Python 3.10:

Python 3.10.0 (default, Oct  4 2021, 22:09:55) [GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from typing import ForwardRef
>>> ForwardRef('asdf') | ForwardRef('fdsa')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'ForwardRef' and 'ForwardRef'
>>> int | str
int | str
>>>

----------
messages: 404037
nosy: bobbeyreese
priority: normal
severity: normal
status: open
title: ForwardRef does not support | operator
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 15 13:43:25 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2021 17:43:25 +0000
Subject: [New-bugs-announce] [issue45490] [meta][C API] Avoid C macro
 pitfalls and usage of static inline functions
Message-ID: <1634319805.82.0.902360778503.issue45490@roundup.psfhosted.org>


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

C macros are really cool and useful, but there are a bunch of pitfalls which are better to avoid:
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html

Some macros of the Python C API have been converted to static inline functions over the last years. It went smoothly, I am not aware of any major issue with these conversions.

This meta issue tracks other issues related to macros and static inline functions.


=== Return void ===

One issue is that some macros are treated as an expression and can be reused, whereas it was not intended. For example PyList_SET_ITEM() was implemented as (simplified code):

  #define PyList_SET_ITEM(op, i, v) (op->ob_item[i] = v)

This expression has a value! Two projects used this value by mistake, like:

  "if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)"

PyList_SET_ITEM() was fixed by casting the expression to void:

  #define PyList_SET_ITEM(op, i, v) ((void)(op->ob_item[i] = v))

=> bpo-30459



=== Abuse macros as an l-value ===

The Py_TYPE() macro could be used to assign a value: "Py_TYPE(obj) = new_type".

The macro was defined as:

  #define Py_TYPE(ob) (ob->ob_type)

It was converted to a static inline function to disallow using it as an l-value and a new Py_SET_TYPE(op, new_type) function was added. These changes give more freedom to other Python implementations to implement "PyObject" and Py_SET_TYPE().

=> bpo-45476 "[C API] Disallow using PyFloat_AS_DOUBLE() as l-value"
=> bpo-39573 PyObject Py_TYPE/Py_SET_TYPE


=== C API: Macros and embedded Python ===

Sadly, only symbols exported by libpython are accessible to other programming languages embedding Python. Macros of the Python C API are simply not available to them. Projects embedding Python have to hardcode constants and copy macros to their own language, with the risk of being outdated when Python macros are updated.

Even some projects written in C cannot use macros, because they only use libpython symbols. The vim text editor embeds Python this way.

Also, macros are simply excluded from the Python stable ABI (PEP 384).


=== Performance of static inline functions ===

In bpo-45116, it seems like _PyEval_EvalFrameDefault() reached Visual Studio thresholds and some static inline functions are no longer inlined (Py_INCREF/Py_DECREF).

I also noticed that when Python is built in debug mode in Visual Studio, static inline functions are not inlined. Well, the compiler is free to not inline in debug mode. I guess that GCC and clang also skip inlining using -Og and/or -O0 optimization levels. Using __forceinline and __attribute__((always_inline)) on static inline functions (Py_INCREF, Py_TYPE) for debug builds was discussed in bpo-45094, but the idea was rejected.

On the other side, sometimes it's better to *disable* inlining on purpose to reduce the stack memory consumption, using the Py_NO_INLINE macro. See recent measurements of the stack memory usage:
https://bugs.python.org/issue45439#msg403768

In GH-28893, I noticed that converting a static inline function (PyObject_CallOneArg) to a regular function made it faster. I am not really sure, more benchmarks should be run to really what's going on.


=== Advantages of static inline functions ===

* It's possible to put a breakpoint on a static inline functions.

* Debuggers and profilers are able to get the static inline function names from the machine line, even with inline functions.

* Parameters and the return value have well defined types.

* Variables have a local scope.

* There is no risk of evaluating an expression multiple times.

* Regular C code. No need to use "\" character to multi-line statement. No need for "do { ... } while (0)" and other quicks to workaround preprocessor pitfalls. No abuse of (((parenthesis))).

----------
components: C API
messages: 404038
nosy: vstinner
priority: normal
severity: normal
status: open
title: [meta][C API] Avoid C macro pitfalls and usage of static inline functions
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 15 17:29:28 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Oct 2021 21:29:28 +0000
Subject: [New-bugs-announce] [issue45491] help() is too noisy for types used
 like functions
Message-ID: <1634333368.34.0.317512316582.issue45491@roundup.psfhosted.org>


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

When someone requests help(range), help(zip), help(property), or help(classmethod), the expectation and need is to see something like what is shown in main documentation rather than being subjected to a listing of every standard dunder method.

It would be nice to have a way to mark types that are mostly used like functions so that help() output will be more focused and less noisy.  Then help() can omit the Methods and Static methods sections.  It would keep the section for non-standard descriptors such as start, stop, step, fget, fset, or fdel.

Alternatively, for all types, we can condense the Methods and Static Methods sections to just list the standard dunder methods rather that eating several rows of output per method.

----------
components: Library (Lib)
messages: 404050
nosy: rhettinger
priority: normal
severity: normal
status: open
title: help() is too noisy for types used like functions
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Oct 16 06:45:28 2021
From: report at bugs.python.org (Dutcho)
Date: Sat, 16 Oct 2021 10:45:28 +0000
Subject: [New-bugs-announce] [issue45492] stdlib inspect documentation on
 code.co_names is incorrect
Message-ID: <1634381128.63.0.689395571563.issue45492@roundup.psfhosted.org>


New submission from Dutcho <dutcho at ziggo.nl>:

The standard library documentation on module inspect starts with an overview of types and attributes. This overview (in all Python versions) states:
    code.co_names: tuple of names of local variables
    code.co_varnames: tuple of names of arguments and local variables
That suggests the argument names are set(code.co_varnames) - set(code.co_names), which is incorrect.

I think the attribute description should be:
    code.co_names: tuple of names of used global and built-in variables

>>> def f(x): a = 1; print(f, a)
>>> assert f.__code__.co_varnames == ('x', 'a')  # argument and local, in that order
>>> assert set(f.__code__.co_names) == set(('f', 'print'))  # global and built-in (don't care order), not local

----------
assignee: docs at python
components: Documentation
messages: 404068
nosy: Dutcho, docs at python
priority: normal
severity: normal
status: open
title: stdlib inspect documentation on code.co_names is incorrect
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/issue45492>
_______________________________________

From report at bugs.python.org  Sat Oct 16 06:58:57 2021
From: report at bugs.python.org (Dutcho)
Date: Sat, 16 Oct 2021 10:58:57 +0000
Subject: [New-bugs-announce] [issue45493] str() and repr() of enum different
 in Python 3.11 from from Python <= 3.10
Message-ID: <1634381937.08.0.264995167777.issue45493@roundup.psfhosted.org>


New submission from Dutcho <dutcho at ziggo.nl>:

See below example, which shows Python 3.11 repr(enum) == Python 3.10 str(enum).

The enum module documentation lists various enhancements in 3.11, but not this.
And the what's new? documentation of 3.11 doesn't mention enum at all.

Either this is by intent, and then should be documented incl. breaking old code depending on representation, or is by accident, and then merits fixing (which is what alphas are for).

> py -3.10 enum_test.py
3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)]
ABC.a ABC.b ABC.c ABC.a <ABC.a: 1>

> py -3.11 enum_test.py
3.11.0a1 (tags/v3.11.0a1:7c12e48, Oct  5 2021, 15:38:19) [MSC v.1929 64 bit (AMD64)]
a b c a ABC.a

> more enum_test.py
import enum
import sys


class ABC(enum.Enum):
    a = enum.auto()
    b = enum.auto()
    c = enum.auto()


print(sys.version)
print(*ABC, str(ABC.a), repr(ABC.a))

----------
components: Library (Lib)
messages: 404069
nosy: Dutcho
priority: normal
severity: normal
status: open
title: str() and repr() of enum different in Python 3.11 from from Python <= 3.10
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Oct 16 10:24:17 2021
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 16 Oct 2021 14:24:17 +0000
Subject: [New-bugs-announce] [issue45494] [fuzzer] Parser null deref with
 continuation characters and generator parenthesis error
Message-ID: <1634394257.16.0.767966008926.issue45494@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

Another parser crash found by the fuzzer:

"\
"(1for c in I,\
\

Recreator:

>>> import ast
>>> ast.literal_eval('"\\\n"(1for c in I,\\\n\\')
[1]    17916 segmentation fault  ./python

>>> import ast
>>> ast.literal_eval(r'''
... "\
... "(1for c in I,\
... \ ''')
[1]    17935 segmentation fault  ./python


-------------------
Raw ASAN stacktrace
-------------------

	==1668==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f4157e5e08c bp 0x7fffbd48b300 sp 0x7fffbd48aab8 T0)
==1668==The signal is caused by a READ memory access.
==1668==Hint: address points to the zero page.
    #0 0x7f4157e5e08c in strchr-avx2.S:57 /build/glibc-eX1tMB/glibc-2.31/sysdeps/x86_64/multiarch/strchr-avx2.S:57
    #1 0x4d7a88 in strchr /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:0
    #2 0x9fa6f5 in get_error_line cpython3/Parser/pegen.c:406:25
    #3 0x9fa6f5 in _PyPegen_raise_error_known_location cpython3/Parser/pegen.c:497:26
    #4 0xa18a92 in RAISE_ERROR_KNOWN_LOCATION cpython3/Parser/pegen.h:169:5
    #5 0xa331d5 in invalid_arguments_rule cpython3/Parser/parser.c:17831:20
    #6 0xa21a87 in arguments_rule cpython3/Parser/parser.c:15462:38
    #7 0xa2056b in primary_raw cpython3/Parser/parser.c:12867:18
    #8 0xa2056b in primary_rule cpython3/Parser/parser.c:12745:22
    #9 0xa1f9cd in await_primary_rule cpython3/Parser/parser.c:12700:28
    #10 0xa1f119 in power_rule cpython3/Parser/parser.c:12578:18
    #11 0xa1eabc in factor_rule cpython3/Parser/parser.c:12530:26
    #12 0xa1dc04 in term_raw cpython3/Parser/parser.c:12373:27
    #13 0xa1dc04 in term_rule cpython3/Parser/parser.c:12138:22
    #14 0xa1c899 in sum_raw cpython3/Parser/parser.c:12093:25
    #15 0xa1c899 in sum_rule cpython3/Parser/parser.c:11975:22
    #16 0xa1bb99 in shift_expr_raw cpython3/Parser/parser.c:11936:24
    #17 0xa1bb99 in shift_expr_rule cpython3/Parser/parser.c:11818:22
    #18 0xa1af2c in bitwise_and_raw cpython3/Parser/parser.c:11779:31
    #19 0xa1af2c in bitwise_and_rule cpython3/Parser/parser.c:11700:22
    #20 0xa1a49c in bitwise_xor_raw cpython3/Parser/parser.c:11661:32
    #21 0xa1a49c in bitwise_xor_rule cpython3/Parser/parser.c:11582:22
    #22 0xa1917c in bitwise_or_raw cpython3/Parser/parser.c:11543:32
    #23 0xa1917c in bitwise_or_rule cpython3/Parser/parser.c:11464:22
    #24 0xa2cd39 in comparison_rule cpython3/Parser/parser.c:10727:18
    #25 0xa2c912 in inversion_rule cpython3/Parser/parser.c:10680:31
    #26 0xa2b951 in conjunction_rule cpython3/Parser/parser.c:10559:18
    #27 0xa258e1 in disjunction_rule cpython3/Parser/parser.c:10473:18
    #28 0xa17cb1 in invalid_expression_rule cpython3/Parser/parser.c:18253:18
    #29 0xa17cb1 in expression_rule cpython3/Parser/parser.c:9754:39
    #30 0xa56979 in expressions_rule cpython3/Parser/parser.c:9628:18
    #31 0xa0acf5 in eval_rule cpython3/Parser/parser.c:1035:18
    #32 0xa0acf5 in _PyPegen_parse cpython3/Parser/parser.c:33076:18
    #33 0xa001a5 in _PyPegen_run_parser cpython3/Parser/pegen.c:1350:9
    #34 0xa01fa5 in _PyPegen_run_parser_from_string cpython3/Parser/pegen.c:1482:14
    #35 0xa80fc9 in _PyParser_ASTFromString cpython3/Parser/peg_api.c:14:21
    #36 0x8611ca in Py_CompileStringObject cpython3/Python/pythonrun.c:1371:11
    #37 0xc04a8f in builtin_compile_impl cpython3/Python/bltinmodule.c:842:14
    #38 0xc04a8f in builtin_compile cpython3/Python/clinic/bltinmodule.c.h:249:20
    #39 0xb78ade in cfunction_vectorcall_FASTCALL_KEYWORDS cpython3/Objects/methodobject.c:446:24
    #40 0x57c0ec in _PyObject_VectorcallTstate cpython3/Include/internal/pycore_call.h:89:11
    #41 0x57c0ec in PyObject_Vectorcall cpython3/Objects/call.c:298:12
    #42 0x766191 in call_function cpython3/Python/ceval.c:6619:13
    #43 0x748137 in _PyEval_EvalFrameDefault cpython3/Python/ceval.c:4734:19
    #44 0x741ae4 in _PyEval_EvalFrame cpython3/Include/internal/pycore_ceval.h:48:16
    #45 0x741ae4 in _PyEval_Vector cpython3/Python/ceval.c:5810:24
    #46 0x57cb50 in _PyFunction_Vectorcall cpython3/Objects/call.c:0
    #47 0x57c0ec in _PyObject_VectorcallTstate cpython3/Include/internal/pycore_call.h:89:11
    #48 0x57c0ec in PyObject_Vectorcall cpython3/Objects/call.c:298:12
    #49 0x766191 in call_function cpython3/Python/ceval.c:6619:13
    #50 0x748137 in _PyEval_EvalFrameDefault cpython3/Python/ceval.c:4734:19
    #51 0x741ae4 in _PyEval_EvalFrame cpython3/Include/internal/pycore_ceval.h:48:16
    #52 0x741ae4 in _PyEval_Vector cpython3/Python/ceval.c:5810:24
    #53 0x57cb50 in _PyFunction_Vectorcall cpython3/Objects/call.c:0
    #54 0x57c920 in _PyObject_VectorcallTstate cpython3/Include/internal/pycore_call.h:89:11
    #55 0x57c920 in PyObject_CallOneArg cpython3/Objects/call.c:375:12
    #56 0x579d18 in fuzz_ast_literal_eval cpython3/Modules/_xxtestfuzz/fuzzer.c:425:25
    #57 0x579d18 in _run_fuzz cpython3/Modules/_xxtestfuzz/fuzzer.c:443:14
    #58 0x579d18 in LLVMFuzzerTestOneInput cpython3/Modules/_xxtestfuzz/fuzzer.c:565:11
    #59 0x472623 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) cxa_noexception.cpp:0
    #60 0x45ded2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
    #61 0x463985 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) cxa_noexception.cpp:0
    #62 0x48c672 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #63 0x7f4157cfa0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16
    #64 0x43b16d in _start

----------
components: Parser
messages: 404082
nosy: ammar2, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: [fuzzer] Parser null deref with continuation characters and generator parenthesis error
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Sat Oct 16 10:24:45 2021
From: report at bugs.python.org (Julien Palard)
Date: Sat, 16 Oct 2021 14:24:45 +0000
Subject: [New-bugs-announce] [issue45495] IDLE: Add match and case
Message-ID: <1634394285.54.0.829596302519.issue45495@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In IDLE, when hitting Ctrl-space on `matc` or `cas`, there's no completion to `match` and `case.

References: https://mail.python.org/archives/list/docs at python.org/thread/DRZIHLQU25JUD7IQKCOIIKI4ADB746MA/

----------
assignee: terry.reedy
components: IDLE
messages: 404083
nosy: mdk, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Add match and case
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Oct 16 12:29:00 2021
From: report at bugs.python.org (E. Paine)
Date: Sat, 16 Oct 2021 16:29:00 +0000
Subject: [New-bugs-announce] [issue45496] Tkinter: test_winfo_rgb failure
Message-ID: <1634401740.26.0.645054867141.issue45496@roundup.psfhosted.org>


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

This issue is to separately address the test_winfo_rgb failure reported by myself in #43139. This issue does not currently affect any of the buildbots.

---

On one computer I am experiencing a problem with the test_winfo_rgb test:

======================================================================
FAIL: test_winfo_rgb (tkinter.test.test_tkinter.test_misc.MiscTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/cpython/Lib/tkinter/test/test_tkinter/test_misc.py", line 213, in test_winfo_rgb
    self.assertEqual(rgb('#4a3c8c'), (0x4a4a, 0x3c3c, 0x8c8c))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Tuples differ: (19016, 15399, 35985) != (19018, 15420, 35980)

First differing element 0:
19016
19018

- (19016, 15399, 35985)
?      ^    ^^^      ^

+ (19018, 15420, 35980)
?      ^    ^^^      ^

I have tested another computer with a very similar setup (Plasma on X11) with exactly the same monitor (both using HDMI) and it passed this test. The only notable difference is one computer is using Intel integrated graphics while the other is Nvidia.

----------
components: Tests, Tkinter
messages: 404097
nosy: epaine, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: Tkinter: test_winfo_rgb failure
versions: Python 3.11

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

From report at bugs.python.org  Sat Oct 16 14:42:33 2021
From: report at bugs.python.org (Shivnaren Srinivasan)
Date: Sat, 16 Oct 2021 18:42:33 +0000
Subject: [New-bugs-announce] [issue45497] Argparse: Refactor '%'
 interpolation to f-strings
Message-ID: <1634409753.34.0.421014561785.issue45497@roundup.psfhosted.org>


New submission from Shivnaren Srinivasan <shivnaren at gmail.com>:

I use `argparse` a lot, and I think it's great?going through the source code, I see all string interpolation is with the old printf `%` formatting.

AFAIK, f-strings are now the suggested method for interpolation (*after they were introduced, that is*).

Do we want to refactor the '%' instances to f-strings? Happy to submit a PR if so.

----------
components: Library (Lib)
messages: 404108
nosy: rhettinger, shivnaren
priority: normal
severity: normal
status: open
title: Argparse: Refactor '%' interpolation to f-strings
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat Oct 16 16:59:22 2021
From: report at bugs.python.org (Lahfa Samy)
Date: Sat, 16 Oct 2021 20:59:22 +0000
Subject: [New-bugs-announce] [issue45498] [doc] Fix a code example,
 non declared variable being printed
Message-ID: <1634417962.21.0.795610058247.issue45498@roundup.psfhosted.org>


New submission from Lahfa Samy <lahfa121999 at gmail.com>:

I was looking through the documentation at examples for reading CSV files and noticed that an undefined variable was printed in a code example, this affects Python version from 3.6 till 3.110a1 (dev version of the documentation).

It got me kind of confused, because a for loop does not really declare variables.
The fix is really simple, just printing the variable that is declared.

----------
assignee: docs at python
components: Documentation
files: csv-example-fix.patch
keywords: patch
messages: 404115
nosy: AkechiShiro, docs at python
priority: normal
severity: normal
status: open
title: [doc] Fix a code example, non declared variable being printed
type: enhancement
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/file50365/csv-example-fix.patch

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

From report at bugs.python.org  Sun Oct 17 00:50:55 2021
From: report at bugs.python.org (theeshallnotknowethme)
Date: Sun, 17 Oct 2021 04:50:55 +0000
Subject: [New-bugs-announce] [issue45499] from __future__ import annotations
 is not mandatory in 3.11.0a1+
Message-ID: <1634446255.85.0.0444213933031.issue45499@roundup.psfhosted.org>


New submission from theeshallnotknowethme <nohackingofkrowten at gmail.com>:

>>> import sys
>>> import __future__
>>> __future__.annotations
_Feature((3, 7, 0, 'beta', 1), (3, 11, 0, 'alpha', 0), 16777216)
>>> sys.version_info
sys.version_info(major=3, minor=11, micro=0, releaselevel='alpha', serial=1)
>>> sys.version_info > __future__.annotations.mandatory
True
>>> sys.version_info >= __future__.annotations.mandatory
True

Why is it still not automatically inside python 3.11.0a1?

----------
components: Installation
messages: 404125
nosy: February291948
priority: normal
severity: normal
status: open
title: from __future__ import annotations is not mandatory in 3.11.0a1+
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sun Oct 17 05:55:33 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Oct 2021 09:55:33 +0000
Subject: [New-bugs-announce] [issue45500] Rewrite test_dbm
Message-ID: <1634464533.25.0.959205582661.issue45500@roundup.psfhosted.org>


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

* Generate test classes at import time. It allows to filter them when run with unittest. E.g: "./python -m unittest test.test_dbm.TestCase_gnu -v".
* Create a database class in a new directory which will be removed after test. It guarantees that all created files and directories be removed and will not conflict with other dbm tests.
* Restore dbm._defaultmod after tests. Previously it was set to the last dbm module (dbm.dumb) which affected other tests.
* Enable the whichdb test for dbm.dumb.
* Move test_keys to the correct test class. It does not test whichdb().
* Remove some outdated code and comments.

----------
components: Tests
messages: 404131
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Rewrite test_dbm
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Oct 17 06:10:17 2021
From: report at bugs.python.org (Julien Palard)
Date: Sun, 17 Oct 2021 10:10:17 +0000
Subject: [New-bugs-announce] [issue45501] [idea] Successfully creating a
 venv could print a message.
Message-ID: <1634465417.7.0.0888644827871.issue45501@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

I realized that many students get surprised by `python -m venv .venv` not printing anything, a few even think it completly failed.

I'm OK teaching them this is normal, as `mv`, `cp`, `rm`, `django-admin startproject`, ... does not print neither when they succeed.

But I fear many other Python users could be surprised too and not have a teacher around to reassure them.

I kept this as a status-quo for years but thinking of it today I though ??And why not telling them how to activate the venv???

Would'nt it be great to have:

    $ python3 -m venv .venv
    Environment created successfully, activate it using:

        source .venv/bin/activate

or

    PS C:\Users\Admin> python3 -m venv .venv
    Environment created successfully, activate it using:

        .venv\Scripts\Activate.ps1

and so on?

A `-q`/`--quiet` could be added for scripts creating venvs.

----------
messages: 404132
nosy: mdk
priority: normal
severity: normal
status: open
title: [idea] Successfully creating a venv could print a message.

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

From report at bugs.python.org  Sun Oct 17 06:15:57 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Oct 2021 10:15:57 +0000
Subject: [New-bugs-announce] [issue45502] Fix test_shelve and make it
 discoverable
Message-ID: <1634465757.41.0.209752823951.issue45502@roundup.psfhosted.org>


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

test_shelve was intended to run some tests for all underlying dbm implementation, but since b17acad68ea21c60dbc2088644f2934032304628 (at May 2008) it runs them with the same implementation.

The proposed PR fixes this regression and also makes test_shelve discoverable, so it can be run with the unittest module.

----------
components: Tests
messages: 404133
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix test_shelve and make it discoverable
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Oct 17 07:35:30 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 17 Oct 2021 11:35:30 +0000
Subject: [New-bugs-announce] [issue45503] Several improvement point of gdbm
 module
Message-ID: <1634470530.26.0.70415684726.issue45503@roundup.psfhosted.org>


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

I have a chance to exchange mail with gdbm module maintainer Sergey Poznyakoff to supporting the crash tolerance feature.
(See bpo-45452) 

Other dbm modules also might have the same issue what the maintainer pointed out.

I copy and paste the content that gdbm maintainer's pointed out.

I would like to listen to other core dev's opinions about the gdbm moudle and also other dbm module interface improvements.
I add the core devs who might have an interest in this issue.

Personally, I have interests in Error handling and items() and values() methods issues.


1. Error handling

The most problematic place.  Most methods throw an error in case of
failure, which is quite OK.  However, to do so they use PyErr_SetString
and PyErr_SetFromErrno family functions, passing the gdbm_errno value
as their argument.  This is plain wrong.  These functions treat the
errno argument as a value of C "errno" variable.  Obviously, gdbm_errno
codes have diffeent meanings, so the resulting diagnostics is misleading
if not downright unusable.

2. Lack of interfaces for database export/import (gdbm_dump and
gdbm_load functions).  This is quite an important aspect, in particular
for handling database backups.

3. Lack of interface for database recovery (gdbm_recover function).

4. The items() and values() methods are not supported.  These should be
easy to implement using gdbm_firstkey/gdbm_nextkey.

----------
messages: 404136
nosy: corona10, methane, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Several improvement point of gdbm module

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

From report at bugs.python.org  Sun Oct 17 22:01:44 2021
From: report at bugs.python.org (Steven)
Date: Mon, 18 Oct 2021 02:01:44 +0000
Subject: [New-bugs-announce] [issue45504] [argparse] Entering a partial
 config_parser flag works with subparsers
Message-ID: <1634522504.9.0.975535352366.issue45504@roundup.psfhosted.org>


New submission from Steven <steven at swills.me>:

I have a package with a module called `commands.py`. This file is basically three sub parsers and an entry point. 

Here is one of my subparsers. It shows the current path of a config file, and lets you update the path if you want.

    #config sub-command
    config_parser = subparsers.add_parser('config')
    config_parser.set_defaults(func=config_path)
    config_parser.add_argument('--show', help='show current config file path - takes no input', action='store_true')
    config_parser.add_argument('--update', help='modify config file path', dest='path')

If you look at the first config_parser which is `--show`. Notice how it doesn't take an input. You just pass in --show and it prints the config path to the cli.

Here is the function that tells --show what to do.;

    def config_path(args):
        dotenv_file = dotenv.find_dotenv()
        dotenv.load_dotenv(dotenv_file)
        if args.show:
            print(os.environ['FILE_PATH']) 
        elif args.path:
            os.environ['FILE_PATH'] = args.path
            dotenv.set_key(dotenv_file, 'FILE_PATH', os.environ['FILE_PATH'])

This is what my entrypoints in my setup.py looks like.

    entry_points={
            'console_scripts': [
                #command = package.module:function
                'conftool = conftool.commands:main',
            ],
        }
    )

All of the following work

    conftool config --s
    conftool config --sh
    conftool config --sho
    conftool config --show

I have another sub parser and function like the one above. The config_parser is basically the same. It has an option that doesn't take an argument and store is true. They behave the same way. The other function and subparser have an option that is `--gettoken`. It works with --g, --ge, --get, --gett, --getto, --gettok, gettoke.

Is this possibly a bug?

----------
components: Parser
messages: 404153
nosy: lys.nikolaou, pablogsal, swills1
priority: normal
severity: normal
status: open
title: [argparse] Entering a partial config_parser flag works with subparsers
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 18 01:30:14 2021
From: report at bugs.python.org (Jan Wolski)
Date: Mon, 18 Oct 2021 05:30:14 +0000
Subject: [New-bugs-announce] [issue45505] Remove unneeded ZipFile IO
Message-ID: <1634535014.34.0.466383948896.issue45505@roundup.psfhosted.org>


New submission from Jan Wolski <jan at wolski.fi>:

Currently in the ZipFile class implementation, when processing the zip file headers "extra" field, a .read() call is used without using the returned value in any way. This call could be replaced with a .seek() to avoid actually doing the IO.

The change would improve performance in use cases where the fileobject given to ZipFile is backed by high latency IO, eg. HTTP range requests.

----------
components: Library (Lib)
messages: 404155
nosy: data-ux
priority: normal
pull_requests: 27292
severity: normal
status: open
title: Remove unneeded ZipFile IO
type: performance

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

From report at bugs.python.org  Mon Oct 18 03:53:48 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Oct 2021 07:53:48 +0000
Subject: [New-bugs-announce] [issue45506] Out of source tree builds failing
 on main - test_importlib others unreliable
Message-ID: <1634543628.08.0.540033030663.issue45506@roundup.psfhosted.org>


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

The behavior is odd, I don't really know how to characterize it other than something serious has gone wrong.  Memory corruption thus differing failures perhaps?  it seems like maybe a race condition?

on the main branch (i cannot reproduce this on 3.10 thankfully):

1) git checkout https://github.com/python/cpython.git upstream
2) mkdir b-u && cd b-u
3) ../upstream/configure --with-pydebug && make -j3 && ./python -m test.regrtest test_importlib

- sometimes it hangs forever.
- sometimes it crashes with a long list of error messages coming out of regrtest itself.  The crashes appear to happen in a child process so regrtest can continue and run other tests if you tell it to run more.  Sometimes it'll be an error about "import _frozenimport_lib as bootstrap" failing with sys.modules containing None. (Linux does that for me)  On macOS when it doesn't hang, I get a blowup from test_importlib/test_threaded_import.py.

I've reproduced this on Linux and macOS.  macOS alternates between a traceback blowup and hang with an occasional pass.  On Linux it is quite consistently a huge chain of stacktraces.

Linux:

```
0:00:00 load avg: 2.48 Run tests sequentially
0:00:00 load avg: 2.48 [1/1] test_importlib
Failed to import test module: test.test_importlib.builtin.test_finder
Traceback (most recent call last):
  File "/home/greg/oss/python/cpython/gpshead/Lib/importlib/__init__.py", line 16, in <module>
    import _frozen_importlib as _bootstrap
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: import of _frozen_importlib halted; None in sys.modules

During handling of the above exception, another exception occurred:

...  tons more  ...
```

Our buildbot fleet is not bloody looking.  Which is why I tried it on two different systems and OSes before reporting.  When I do a ./configure and run everything within the source tree it does not fail.  This is only for proper out-of-tree builds (which are what I always use - as should everybody).

Do our buildbots only do in-tree builds?

----------
components: Build
messages: 404159
nosy: gregory.p.smith
priority: high
severity: normal
stage: needs patch
status: open
title: Out of source tree builds failing on main - test_importlib others unreliable
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 18 04:51:32 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Mon, 18 Oct 2021 08:51:32 +0000
Subject: [New-bugs-announce] [issue45507] Small oversight in 3.11
 gzip.decompress implementation with regards to backwards compatibility
Message-ID: <1634547092.41.0.572458235667.issue45507@roundup.psfhosted.org>


New submission from Ruben Vorderman <r.h.p.vorderman at lumc.nl>:

A 'struct.error: unpack requires a buffer of 8 bytes' is thrown when a gzip trailer is truncated instead of an EOFError such as in the 3.10 and prior releases.

----------
components: Library (Lib)
messages: 404165
nosy: rhpvorderman
priority: normal
severity: normal
status: open
title: Small oversight in 3.11 gzip.decompress implementation with regards to backwards compatibility
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 18 05:49:42 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 18 Oct 2021 09:49:42 +0000
Subject: [New-bugs-announce] [issue45508] Specialize INPLACE_ADD
Message-ID: <1634550582.0.0.584054071431.issue45508@roundup.psfhosted.org>


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

I ran on WSL with PGO and got "1.00x faster":
https://gist.github.com/sweeneyde/41a76356e875e2a98d16ce5410ab41c0

My benchmarking doesn't seem particularly reliable, so someone else should probably verify.

Great specialization stats, except for telco, which uses decimal += decimal.

bm_fannkuch:
    inplace_add.specialization_success : 23
    inplace_add.specialization_failure : 3
    inplace_add.hit : 7968285
    inplace_add.deferred : 198
    inplace_add.miss : 39
    inplace_add.deopt : 3
    inplace_add.unquickened : 168

bm_nbody:
    inplace_add.specialization_success : 27
    inplace_add.specialization_failure : 3
    inplace_add.hit : 3600615
    inplace_add.deferred : 198
    inplace_add.miss : 39
    inplace_add.deopt : 3
    inplace_add.unquickened : 178

bm_spectral_norm:
    inplace_add.specialization_success : 24
    inplace_add.specialization_failure : 5
    inplace_add.hit : 2684690
    inplace_add.deferred : 326
    inplace_add.miss : 20843
    inplace_add.deopt : 3
    inplace_add.unquickened : 171

bm_telco:
    inplace_add.specialization_success : 21
    inplace_add.specialization_failure : 18537
    inplace_add.hit : 597
    inplace_add.deferred : 1186282
    inplace_add.miss : 39
    inplace_add.deopt : 3
    inplace_add.unquickened : 187

----------
messages: 404171
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Specialize INPLACE_ADD

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

From report at bugs.python.org  Mon Oct 18 06:41:07 2021
From: report at bugs.python.org (Ruben Vorderman)
Date: Mon, 18 Oct 2021 10:41:07 +0000
Subject: [New-bugs-announce] [issue45509] Gzip header corruption not
 properly checked.
Message-ID: <1634553667.76.0.606198171759.issue45509@roundup.psfhosted.org>


New submission from Ruben Vorderman <r.h.p.vorderman at lumc.nl>:

The following headers are currently allowed while being wrong:

- Headers with FCOMMENT flag set, but with incomplete or missing COMMENT bytes.
- Headers with FNAME flag set, but with incomplete or missing NAME bytes
- Headers with FHCRC set, the crc is read, but not checked.

----------
components: Library (Lib)
messages: 404174
nosy: rhpvorderman
priority: normal
severity: normal
status: open
title: Gzip header corruption not properly checked.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 18 07:14:17 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 18 Oct 2021 11:14:17 +0000
Subject: [New-bugs-announce] [issue45510] Specialize BINARY_SUBTRACT
Message-ID: <1634555657.96.0.480345209598.issue45510@roundup.psfhosted.org>


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

https://github.com/faster-cpython/ideas/issues/100

----------
messages: 404176
nosy: corona10
priority: normal
severity: normal
status: open
title: Specialize BINARY_SUBTRACT
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 18 08:32:04 2021
From: report at bugs.python.org (Romuald Brunet)
Date: Mon, 18 Oct 2021 12:32:04 +0000
Subject: [New-bugs-announce] [issue45511] input() method limited to 4095
 characters on *NIX
Message-ID: <1634560324.05.0.266580517788.issue45511@roundup.psfhosted.org>


New submission from Romuald Brunet <romuald.brunet at gmail.com>:

When run in non-interactive mode and with a TTY stdin, the input() method will not read more than 4095 characters

Simple example:

>>> foo = input()  # paste a 5000 character pasteboard (one line)
>>> print(len(foo))
4095

Note that this will **not** happen when using an interactive shell (using python -i on the same script will not have the 4095 limit)

I've traced the issue (I think) to the fgets function called from my_fgets in myreadline.c, but I have no clue as to how one might fix this.

----------
components: Interpreter Core
messages: 404179
nosy: Romuald
priority: normal
severity: normal
status: open
title: input() method limited to 4095 characters on *NIX
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 18 08:59:11 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 18 Oct 2021 12:59:11 +0000
Subject: [New-bugs-announce] [issue45512] [sqlite3] simplify "isolation
 level"
Message-ID: <1634561951.05.0.13174221264.issue45512@roundup.psfhosted.org>


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

While working on bpo-45126 / GH-28227 (and while working on the AC conversion, bpo-40956), I've been slightly frustrated on the implementation of sqlite3 "isolation level". The code is messy, and we've got two connection members that carry pretty much the same type of information (self->isolation_level, and self->begin_statement).

I would like to make the following enhancements:
  - merge 'isolation_level' and 'begin_statement' members in some kind of way
  - split pysqlite_connection_set_isolation_level():
    + one method for parsing and storing the 'isolation_level' member
    + one method for carrying out any needed SQLite API operation

This should result in a cleaner connection __init__() method.


Another slightly related performance enhancement could be to cache the "begin" (and "commit") statements as sqlite3_stmt pointers on the connection object, but that is a digression.

----------
components: Extension Modules
messages: 404182
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] simplify "isolation level"
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 18 09:31:04 2021
From: report at bugs.python.org (Timothe Litt)
Date: Mon, 18 Oct 2021 13:31:04 +0000
Subject: [New-bugs-announce] [issue45513] PIP error Cannot call rmtree on a
 symbolic link should report the lilnk
Message-ID: <1634563864.17.0.975785076379.issue45513@roundup.psfhosted.org>


New submission from Timothe Litt <tlhackque at yahoo.com>:

Debugging this would be a whole lot easier if the symlink in question was in the error message... (Not to mention that "successfully uninstalled the installer followed by why the new one can't be installed isn't a good thing....)

pip3 install --upgrade pip
Requirement already satisfied: pip in /usr/local/lib/python3.10/site-packages (21.2.3)
Collecting pip
  Using cached pip-21.3-py3-none-any.whl (1.7 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 21.2.3
    Uninstalling pip-21.2.3:
      Successfully uninstalled pip-21.2.3
ERROR: Could not install packages due to an OSError: Cannot call rmtree on a symbolic link

----------
components: Installation
messages: 404186
nosy: tlhackque
priority: normal
severity: normal
status: open
title: PIP error Cannot call rmtree on a symbolic link should report the lilnk
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 18 14:03:23 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Oct 2021 18:03:23 +0000
Subject: [New-bugs-announce] [issue45514] Deprecate legacy functions from
 importlib.resources (importlib_resources 5.3)
Message-ID: <1634580203.88.0.440304730222.issue45514@roundup.psfhosted.org>


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

[importlib_resources 5.3](https://importlib-resources.readthedocs.io/en/latest/history.html#v5-3-0), deprecates the functions in _legacy. Let's introduce that deprecation in CPython also.

In addition to merging the changes from importlib_resources, this change will require some updates to documentation.

----------
assignee: jaraco
components: Library (Lib)
messages: 404205
nosy: FFY00, jaraco
priority: normal
severity: normal
status: open
title: Deprecate legacy functions from importlib.resources (importlib_resources 5.3)
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 18 14:47:36 2021
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 18 Oct 2021 18:47:36 +0000
Subject: [New-bugs-announce] [issue45515] Add reference to zoneinfo in the
 datetime module documetnation
Message-ID: <1634582856.08.0.897823851685.issue45515@roundup.psfhosted.org>


New submission from Paul Ganssle <bpo at m.ganssle.io>:

Right now the datetime documentation recommends using `dateutil.tz` for IANA time zones, but we should update this to point to `zoneinfo`.

----------
assignee: p-ganssle
components: Documentation
messages: 404207
nosy: p-ganssle
priority: low
severity: normal
status: open
title: Add reference to zoneinfo in the datetime module documetnation
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Oct 18 15:07:19 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Mon, 18 Oct 2021 19:07:19 +0000
Subject: [New-bugs-announce] [issue45516] Add protocol description to the
 Traversable and TraversableResources documentation
Message-ID: <1634584039.33.0.945856615309.issue45516@roundup.psfhosted.org>


Change by Filipe La?ns <lains at riseup.net>:


----------
assignee: docs at python
components: Documentation
nosy: FFY00, docs at python
priority: normal
severity: normal
status: open
title: Add protocol description to the Traversable and TraversableResources documentation

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

From report at bugs.python.org  Mon Oct 18 16:37:06 2021
From: report at bugs.python.org (Jesse Kinkead)
Date: Mon, 18 Oct 2021 20:37:06 +0000
Subject: [New-bugs-announce] [issue45517] TarFile.add skips files when
 tarfile name matches a directory
Message-ID: <1634589426.34.0.303079244476.issue45517@roundup.psfhosted.org>


New submission from Jesse Kinkead <jesse.kinkead at gmail.com>:

tarfile.open has a "name" parameter that can be used to open a file for reading or writing in the local filesystem. The documentation is unclear what the purpose is if providing a "fileobj" parameter as well, but it has very surprising behavior when the name matches an existing directory.

Specifically, when you provide a "fileobj" for writing and provide a "name" that matches an existing directory, calling .add() on that directory will have it (and any child files) to be silently skipped.

The desired behavior is either to have the files be added (consistent with "name" being totally ignored), or to have it be an error to provide such a "name" value (either one that matches an existing directory, or to provide one at all when using "fileobj").

----------
components: Library (Lib)
files: repro.py
messages: 404217
nosy: jkinkead
priority: normal
severity: normal
status: open
title: TarFile.add skips files when tarfile name matches a directory
versions: Python 3.8
Added file: https://bugs.python.org/file50367/repro.py

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

From report at bugs.python.org  Mon Oct 18 18:13:39 2021
From: report at bugs.python.org (Bozhi You)
Date: Mon, 18 Oct 2021 22:13:39 +0000
Subject: [New-bugs-announce] [issue45518] Invalid example for typing
Message-ID: <1634595219.24.0.159671466805.issue45518@roundup.psfhosted.org>


New submission from Bozhi You <youbozhi at cs.utexas.edu>:

The first example snippet under https://docs.python.org/3/library/typing.html#type-aliases is invalid to run.

```
Traceback (most recent call last):
  File "main.py", line 1, in <module>
    Vector = list[float]
TypeError: 'type' object is not subscriptable
```

A solution to this may be replacing `list` with `List` from `typing`.

----------
assignee: docs at python
components: Documentation
messages: 404232
nosy: bozhiyou, docs at python
priority: normal
severity: normal
status: open
title: Invalid example for typing
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 18 18:49:58 2021
From: report at bugs.python.org (Ivan Savov)
Date: Mon, 18 Oct 2021 22:49:58 +0000
Subject: [New-bugs-announce] [issue45519] Minor docstring improvement in
 __contains__
Message-ID: <1634597398.51.0.583956979541.issue45519@roundup.psfhosted.org>


New submission from Ivan Savov <ivan.savov at gmail.com>:

Currently,

```
>>> help(list.__contains__)
```
returns
```
Help on wrapper_descriptor:
__contains__(self, key, /)
    Return key in self.
```

Which is a conceptual circular reference,
since `in` is implemented by `__contains__`.

Changing the help string to

"Return True if key in self."

would fix this.

----------
assignee: docs at python
components: Documentation
messages: 404236
nosy: Ivan.Savov, docs at python
priority: normal
severity: normal
status: open
title: Minor docstring improvement in __contains__
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/issue45519>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:18:22 2021
From: report at bugs.python.org (Christina Gorbenko)
Date: Mon, 18 Oct 2021 23:18:22 +0000
Subject: [New-bugs-announce] [issue45520] Frozen dataclass deep copy doesn't
 work with __slots__
Message-ID: <1634599102.35.0.694436062352.issue45520@roundup.psfhosted.org>


New submission from Christina Gorbenko <jfuruness at gmail.com>:

If you define a frozen dataclass with slots and deep copy it, an error will occur. If you run the same code and remove the slots, the error will not occur. I assume this behavior is not intentional? Apologies if I'm submitting this wrong, this is the first time I've submitted an issue here so I'm not quite sure how to do it properly.

Example below:

```
from dataclasses import dataclass
from copy import deepcopy

@dataclass(frozen=True)
class FrozenData:
    # Without slots no errors occur?
    __slots__ = "my_string",

    my_string: str

deepcopy(FrozenData(my_string="initial"))
```

Error that occurs:
```
dataclasses.FrozenInstanceError: cannot assign to field 'my_string'
```

----------
messages: 404245
nosy: jfuruness
priority: normal
severity: normal
status: open
title: Frozen dataclass deep copy doesn't work with __slots__
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Oct 19 01:37:58 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 19 Oct 2021 05:37:58 +0000
Subject: [New-bugs-announce] [issue45521] obmalloc radix tree typo in code
Message-ID: <1634621878.99.0.975140050244.issue45521@roundup.psfhosted.org>


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

There is a typo in the radix tree obmalloc code, spotted by Inada Naoki. 

-#define MAP_TOP_MASK (MAP_BOT_LENGTH - 1)
+#define MAP_TOP_MASK (MAP_TOP_LENGTH - 1)

This should be fixed both in the main branch and in 3.10.x.

----------
assignee: methane
components: Interpreter Core
messages: 404268
nosy: methane, nascheme
priority: high
severity: normal
stage: patch review
status: open
title: obmalloc radix tree typo in code
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Oct 19 07:06:04 2021
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Oct 2021 11:06:04 +0000
Subject: [New-bugs-announce] [issue45522] Allow to build Python without
 freelists
Message-ID: <1634641564.68.0.977403045358.issue45522@roundup.psfhosted.org>


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

Freelists are an optimization trick to avoid allocation and deallocation of commonly used structures. Currently Python has freelists for frame, tuple, float, list, dict, async generators, and context objects. Small ints are also cached.

For experimentation with alternative memory allocators such as mimalloc, I would like to introduce a way to disable freelists. Tuples's _Py_tuple_state struct has a conditional check on #if PyTuple_MAXSAVESIZE > 0. I propose to add same logic to all other structs.

----------
assignee: christian.heimes
components: C API
messages: 404289
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Allow to build Python without freelists
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 19 09:42:01 2021
From: report at bugs.python.org (Manuel)
Date: Tue, 19 Oct 2021 13:42:01 +0000
Subject: [New-bugs-announce] [issue45523] Python3 ThreadingHTTPServer fails
 to send chunked encoded response
Message-ID: <1634650921.13.0.397110972299.issue45523@roundup.psfhosted.org>


New submission from Manuel <manuel.bassani at greenorange.it>:

I'm implementing an HTTPServer class that produces a response with transfer-encoding chunked mode.

I'm sending the chunks as described in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding#chunked_encoding

If I send chunks of length <= 9 bytes the message is received correctly by the client, otherwise when sending chunks of length >= 10 bytes, it seems that some of them are not received and the message remains stuck in the client waiting indefinitely

In attachment an example of the complete code to reproduce the issue, but in short, the following code:

# writing 5 chunks of length 10
for i in range(5):
    text = str(i+1) * 10  # concatenate 10 chars
    chunk = '{0:d}\r\n'.format(len(text)) + text + '\r\n'
    self.wfile.write(chunk.encode(encoding='utf-8'))

# writing close sequence
close_chunk = '0\r\n\r\n'
self.wfile.write(close_chunk.encode(encoding='utf-8'))

Produces:
10\r\n
1111111111\r\n
10\r\n
2222222222\r\n
10\r\n
3333333333\r\n
10\r\n
4444444444\r\n
10\r\n
5555555555\r\n
0\r\n
\r\n

In this case the client hangs several minutes without a response 

But if I use length 9 or less instead for example with

text = str(i+1) * 9

the client receives the correct body and the communication ends correctly (in about 6ms)

The problem persists with both http.server.ThreadingHTTPServer and http.server.HTTPServer
I tried also passing the body as an hard-coded binary string

some version informations:
Python 3.9.2
HTTP Client used: Postman 8.10, curl, Chrome


Thanks a lot for any help
Manuel

----------
files: myserver.py
messages: 404300
nosy: manuel_b
priority: normal
severity: normal
status: open
title: Python3 ThreadingHTTPServer fails to send chunked encoded response
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50369/myserver.py

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

From report at bugs.python.org  Tue Oct 19 10:37:47 2021
From: report at bugs.python.org (Aidan Clark)
Date: Tue, 19 Oct 2021 14:37:47 +0000
Subject: [New-bugs-announce] [issue45524] Cross-module dataclass inheritance
 breaks get_type_hints
Message-ID: <1634654267.46.0.759337669411.issue45524@roundup.psfhosted.org>


New submission from Aidan Clark <aidan.b.clark at gmail.com>:

[I believe this is fundamentally a dataclass version of https://bugs.python.org/issue41249]

When using `from __future__ import annotations`, calling get_type_hints on the constructor of a dataclass B which inherits from a dataclass A defined in another module will error if dataclass A has type hints which are not imported in the module where dataclass B is defined.

This is best shown by example, if you have foo.py:

```
from __future__ import annotations

import collections
import dataclasses

@dataclasses.dataclass
class A:
  x: collections.OrderedDict
```

and then in bar.py:

```
from __future__ import annotations

import foo
import dataclasses
import typing

@dataclasses.dataclass
class B(foo.A):
  pass

typing.get_type_hints(B)
```

the final line will raise "NameError: name 'collections' is not defined".


This code will not error if you do either of the following:
  * add `import collections` to bar.py.
  * remove the __future__ annotations import from both files.


I am not confident enough on the internals of dataclass to suggest a fix, but potentially a similar approach to that which solved the TypedDict equivalent https://bugs.python.org/issue41249 would work?

----------
components: Library (Lib)
messages: 404307
nosy: aidan.b.clark, slebedev
priority: normal
severity: normal
status: open
title: Cross-module dataclass inheritance breaks get_type_hints
type: behavior
versions: Python 3.6, Python 3.9

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

From report at bugs.python.org  Tue Oct 19 11:43:58 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 19 Oct 2021 15:43:58 +0000
Subject: [New-bugs-announce] [issue45525] PyType_Spec basicsize/itemsize
 should allow -1 for "inherit"
Message-ID: <1634658238.19.0.273279060126.issue45525@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

For cases where you aren't adding new C-level state, especially if don't have the superclass' struct available, it would be good to allow inheriting basicsize/itemsize from the superclass.

(SuperType->tp_size is not easily usable for the same reason PyType_FromSpecWithBases exists: on MSVC, if SuperType comes from a different DLL, it is not a constant expression.)

----------
messages: 404311
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: PyType_Spec basicsize/itemsize should allow -1 for "inherit"

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

From report at bugs.python.org  Tue Oct 19 12:48:44 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 19 Oct 2021 16:48:44 +0000
Subject: [New-bugs-announce] [issue45526] Set ADDRESS_BITS to 64 for
 obmalloc radix tree
Message-ID: <1634662124.91.0.148058700143.issue45526@roundup.psfhosted.org>


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

Given this feedback:

https://github.com/python/cpython/pull/14474/files#r725488766

it is perhaps not so safe to assume that only the lower 48 bits of virtual addresses are significant.  I had the idea that Go made similar assumptions but now I'm not sure it does.  There is also a comment in this article about 5-level page tables in Linux:

https://lwn.net/Articles/717293/
https://lwn.net/Articles/717300/

I.e. that Linux does not allocate virtual address space above 47-bit by default.

Setting ADDRESS_BITS to 64 is safer and the performance impact seems small. The virtual memory size of a small Python process goes up a little.  Resident set size doesn't significantly change.  I think the pyperformance changes are just noise.  The pyperformance attached file shows the 3.10 branch with ADDRESS_BITS set to 48 and to 64.

----------
assignee: methane
files: pyperf-compare-addr-64.txt
messages: 404317
nosy: methane, nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: Set ADDRESS_BITS to 64 for obmalloc radix tree
Added file: https://bugs.python.org/file50370/pyperf-compare-addr-64.txt

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

From report at bugs.python.org  Tue Oct 19 13:24:13 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 19 Oct 2021 17:24:13 +0000
Subject: [New-bugs-announce] [issue45527] Reduce overhead for cache hits in
 specialized opcodes.
Message-ID: <1634664253.61.0.347658329299.issue45527@roundup.psfhosted.org>


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

Every time we get a cache hit in, e.g. LOAD_ATTR_CACHED, we increment the saturating counting. Takes a dependent load and a store, as well as the shift. For fast instructions like BINARY_ADD_FLOAT, this represents a significant portion of work done in the instruction.

If we don't bother to record the hit, we reduce the overhead of fast, specialized instructions.

The cost is that may have re-optimize more often.
For those instructions with high hit-to-miss ratios, which is most, this be barely measurable.
The cost for type unstable and un-optimizable instruction shouldn't be much changed.

Initial experiments show ~1% speedup.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 404320
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Reduce overhead for cache hits in specialized opcodes.
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 19 15:32:50 2021
From: report at bugs.python.org (Michael Wayne Goodman)
Date: Tue, 19 Oct 2021 19:32:50 +0000
Subject: [New-bugs-announce] [issue45528] mmap: constants not listed in the
 documentation
Message-ID: <1634671970.69.0.866952550683.issue45528@roundup.psfhosted.org>


New submission from Michael Wayne Goodman <goodman.m.w at gmail.com>:

Some constants mentioned in the mmap module documentation are not listed as module contents (i.e., with permalinks), so the mentions do not appear as links and it's not explicit that they are in the mmap module namespace. For instance, ACCESS_READ is referenced but does not link to anything, whereas MAP_PRIVATE links to the MAP_* constants section below showing that it is available as mmap.MAP_PRIVATE.

Constants available but not listed:

* ACCESS_* constants
  - ACCESS_READ
  - ACCESS_WRITE
  - ACCESS_COPY
  - ACCESS_DEFAULT
* PROT_* constants
  - PROT_READ
  - PROT_WRITE
  - PROT_EXEC (this one isn't even mentioned in the docs)
* ALLOCATIONGRANULARITY
* PAGESIZE

These constants are available and unlisted in the documentation for all active versions of Python (except ACCESS_DEFAULT, which is available from 3.7). In addition, none of the MAP_* constants are listed for Python 3.9 and prior, although they all (except MAP_POPULATE) have been available since at least 3.6.

Since these are valid and available constants in the mmap module, can we list them in the documentation for the appropriate versions?

----------
assignee: docs at python
components: Documentation
messages: 404342
nosy: docs at python, goodmami
priority: normal
severity: normal
status: open
title: mmap: constants not listed in the documentation
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/issue45528>
_______________________________________

From report at bugs.python.org  Tue Oct 19 17:26:07 2021
From: report at bugs.python.org (Clay Massok)
Date: Tue, 19 Oct 2021 21:26:07 +0000
Subject: [New-bugs-announce] [issue45529] checking any object for attr "get"
 always returns True with `hasattr`
Message-ID: <1634678767.24.0.869931041778.issue45529@roundup.psfhosted.org>


New submission from Clay Massok <m.c.massok at gmail.com>:

Any time you use `hasattr` to check if a dict has the attr "get", it returns true.

Uploaded `.py` file has bug example.

----------
components: macOS
files: bug.py
messages: 404353
nosy: m.c.massok, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: checking any object for attr "get" always returns True with `hasattr`
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50371/bug.py

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

From report at bugs.python.org  Tue Oct 19 17:41:29 2021
From: report at bugs.python.org (Tim Peters)
Date: Tue, 19 Oct 2021 21:41:29 +0000
Subject: [New-bugs-announce] [issue45530] Improve listobject.c's
 unsafe_tuple_compare()
Message-ID: <1634679689.66.0.398090356022.issue45530@roundup.psfhosted.org>


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

The code could typically be faster if it did what its comments imply it does: skip the expense of PyObject_RichCompareBool() entirely for the first pair of tuple elements. It actually always calls PyObject_RichCompareBool() on the first pair, and only if that says "not equal" does it use the faster ms->tuple_elem_compare to resolve "ok, so it's less than?".

Instead it could do the first pair before, and entirely apart from, the loop, along the lines of:

- Use ms->tuple_elem_compare to see whether u[0] < v[0]. If so, or if an error, we're done.

- Use ms->tuple_elem_compare to see whether v[0] < u[0]. If so, or if an error, we're done.

Else we can assume u[0] == v[0], and go on to compare u[1:] to v[1:] via a trivial variation of the current code.

In cases where the first pair does resolve it (common!), replacing a PyObject_RichCompareBool() with a ms->tuple_elem_compare can be significantly faster overall.

----------
components: Interpreter Core
messages: 404360
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve listobject.c's unsafe_tuple_compare()
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 19 19:25:44 2021
From: report at bugs.python.org (Finite State Machine)
Date: Tue, 19 Oct 2021 23:25:44 +0000
Subject: [New-bugs-announce] [issue45531] field "mro" behaves strangely in
 dataclass
Message-ID: <1634685944.1.0.123359424978.issue45531@roundup.psfhosted.org>


New submission from Finite State Machine <python at state-machine.ca>:

The following Python script:

    from dataclasses import dataclass

    @dataclass
    class A:
        mro: object
        x: object

Results in the following unexpected exception:

    Traceback (most recent call last):
      File "/Users/dsuffling/.pyenv/versions/3.10.0/lib/python3.10/runpy.py", line 196, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/Users/dsuffling/.pyenv/versions/3.10.0/lib/python3.10/runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "/Users/dsuffling/names/junk.py", line 6, in <module>
        class A:
      File "/Users/dsuffling/.pyenv/versions/3.10.0/lib/python3.10/dataclasses.py", line 1178, in dataclass
        return wrap(cls)
      File "/Users/dsuffling/.pyenv/versions/3.10.0/lib/python3.10/dataclasses.py", line 1169, in wrap
        return _process_class(cls, init, repr, eq, order, unsafe_hash,
      File "/Users/dsuffling/.pyenv/versions/3.10.0/lib/python3.10/dataclasses.py", line 1019, in _process_class
        _init_fn(all_init_fields,
      File "/Users/dsuffling/.pyenv/versions/3.10.0/lib/python3.10/dataclasses.py", line 540, in _init_fn
        raise TypeError(f'non-default argument {f.name!r} '
    TypeError: non-default argument 'x' follows default argument


The name of the first attribute ('mro') is critical; without it the problem does not occur.

It appears that 'mro' is somehow interacting with the 'mro' attribute of the 'type' object.

This issue has been verified to occur with CPython 3.10.0.

----------
components: Library (Lib)
messages: 404378
nosy: finite-state-machine
priority: normal
severity: normal
status: open
title: field "mro" behaves strangely in dataclass
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 19 19:40:13 2021
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Oct 2021 23:40:13 +0000
Subject: [New-bugs-announce] [issue45532] Replace 'default' with 'main' as
 default in sys.version
Message-ID: <1634686813.85.0.311990959144.issue45532@roundup.psfhosted.org>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

sys.version returns '3.10.0 (default, Oct  5 2021, 23:49:26) [GCC 10.2.1 20210110]'

'default' is supposed to represent the name of the branch, and it's been there since the HG days: https://github.com/python/cpython/blob/fc64c351c7757f0ebdb7da65cb74871e494a2add/Modules/getbuildinfo.c#L44

When the code was updated for Git in #27593, the default remained the same: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Modules/getbuildinfo.c#L44

The default should be updated to 'main'.

Note that _Py_gitidentifier is supposed to return meaningful values while building from within a git checkout -- when it fails to do so the default value is used.  This can also be tested through sys._git (which returns ('CPython', '', '')), but at the moment I can't build from a git checkout and verify that _Py_gitidentifier returns the correct branch.  If not, a separate issue should be created.

----------
components: Interpreter Core
messages: 404380
nosy: ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: Replace 'default' with 'main' as default in sys.version
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Oct 20 03:57:12 2021
From: report at bugs.python.org (Yavor Atov)
Date: Wed, 20 Oct 2021 07:57:12 +0000
Subject: [New-bugs-announce] [issue45533] loop.sock_connect doesn't resolve
 the address parameter on Windows
Message-ID: <1634716632.31.0.427704063338.issue45533@roundup.psfhosted.org>


New submission from Yavor Atov <yavor.atov at gmail.com>:

>From https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.sock_connect :

Changed in version 3.5.2: address no longer needs to be resolved. sock_connect will try to check if the address is already resolved by calling socket.inet_pton(). If not, loop.getaddrinfo() will be used to resolve the address.

This used to be true in Python 3.7, but in the newer versions, no resolution is done. It could be seen in the source code - the loop implementation is changed and the new one doesn't resolve the address.

https://github.com/python/cpython/blob/085ccb0f177988065dbe9ef4c5cda434560066bc/Lib/asyncio/proactor_events.py#L703

https://github.com/python/cpython/blob/085ccb0f177988065dbe9ef4c5cda434560066bc/Lib/asyncio/windows_events.py#L576

----------
components: asyncio
messages: 404398
nosy: YAtOff, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: loop.sock_connect doesn't resolve the address parameter on Windows
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/issue45533>
_______________________________________

From report at bugs.python.org  Wed Oct 20 04:57:27 2021
From: report at bugs.python.org (Aritra Sarkar)
Date: Wed, 20 Oct 2021 08:57:27 +0000
Subject: [New-bugs-announce] [issue45534] Failing test_exceptions and
 test_threading
Message-ID: <1634720247.23.0.923721814231.issue45534@roundup.psfhosted.org>


New submission from Aritra Sarkar <aritra1911 at yahoo.com>:

While running `make test` on Python 3.11.0a1, I get this:


== Tests result: FAILURE ==

411 tests OK.

2 tests failed:
    test_exceptions test_threading

14 tests skipped:
    test_devpoll test_gdb test_ioctl test_kqueue test_msilib
    test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly
    test_winconsoleio test_winreg test_winsound test_zipfile64
0:06:19 load avg: 5.05
0:06:19 load avg: 5.05 Re-running failed tests in verbose mode
0:06:19 load avg: 5.05 Re-running test_exceptions in verbose mode (matching: test_name_error_suggestions_do_not_trigger_for_too_many_locals)
test_name_error_suggestions_do_not_trigger_for_too_many_locals (test.test_exceptions.NameErrorTests) ... test test_exceptions failed
FAIL

======================================================================
FAIL: test_name_error_suggestions_do_not_trigger_for_too_many_locals (test.test_exceptions.NameErrorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aritra/local/build/Python-3.11.0a1/Lib/test/test_exceptions.py", line 1843, in test_name_error_suggestions_do_not_trigger_for_too_many_locals
    self.assertNotIn("a1", err.getvalue())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'a1' unexpectedly found in 'Traceback (most recent call last):\n  File "/home/aritra/local/build/Python-3.11.0a1/Lib/test/test_exceptions.py", line 1838, in test_name_error_suggestions_do_not_trigger_for_too_many_locals\n
  f()\n    ^^^\n  File "/home/aritra/local/build/Python-3.11.0a1/Lib/test/test_exceptions.py", line 1835, in f\n    print(a0)\n          ^^\nNameError: name \'a0\' is not defined\n'

----------------------------------------------------------------------
Ran 1 test in 0.006s

FAILED (failures=1)
0:06:19 load avg: 5.05 Re-running test_threading in verbose mode (matching: test_recursion_limit)
test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... test test_threading failed
FAIL

======================================================================
FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aritra/local/build/Python-3.11.0a1/Lib/test/test_threading.py", line 1290, in test_recursion_limit
    self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: -11 != 0 : Unexpected error:

----------------------------------------------------------------------
Ran 1 test in 0.161s

FAILED (failures=1)
2 tests failed again:
    test_exceptions test_threading

== Tests result: FAILURE then FAILURE ==

411 tests OK.

2 tests failed:
    test_exceptions test_threading

14 tests skipped:
    test_devpoll test_gdb test_ioctl test_kqueue test_msilib
    test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly
    test_winconsoleio test_winreg test_winsound test_zipfile64

2 re-run tests:
    test_exceptions test_threading

Total duration: 6 min 19 sec
Tests result: FAILURE then FAILURE




Also here are the CFLAGS I used during the build:

probook $ echo $CFLAGS
-Wall -Wextra -g -O0 -std=c99

----------
components: Tests
messages: 404405
nosy: aritra1911
priority: normal
severity: normal
status: open
title: Failing test_exceptions and test_threading
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 20 06:35:06 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Oct 2021 10:35:06 +0000
Subject: [New-bugs-announce] [issue45535] Enum's dir() does not contain
 inherited members
Message-ID: <1634726106.14.0.525814954361.issue45535@roundup.psfhosted.org>


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

For example:

>>> from enum import *
>>> class E(IntEnum):
...     x = 1
... 
>>> dir(E)
['__class__', '__doc__', '__members__', '__module__', 'x']
>>> E.from_bytes
<built-in method from_bytes of EnumType object at 0x559d47415ce0>
>>> E.to_bytes
<method 'to_bytes' of 'int' objects>
>>> E.numerator
<attribute 'numerator' of 'int' objects>
>>> E.__add__
<slot wrapper '__add__' of 'int' objects>

There are methods and attributes inherited from int, but they are not shown in dir(). As result they are absent in help() and completion does not work for them.

----------
components: Library (Lib)
messages: 404420
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Enum's dir() does not contain inherited members
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Oct 20 06:40:24 2021
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 Oct 2021 10:40:24 +0000
Subject: [New-bugs-announce] [issue45536] Verify OpenSSL APIs in configure
 script
Message-ID: <1634726424.89.0.265888702362.issue45536@roundup.psfhosted.org>


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

In thread [1] Robin Becker requested to check for working OpenSSL in configure script. With reasonable effort it is possible to probe for basic APIs such as minimum SSL and EVP interface.

[1] https://mail.python.org/archives/list/python-dev at python.org/thread/IIFABHN7DOTCXMRQ72SLJSU4VDWRM2HB/

----------
assignee: christian.heimes
components: Build, SSL
messages: 404422
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Verify OpenSSL APIs in configure script
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Oct 20 08:04:52 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 20 Oct 2021 12:04:52 +0000
Subject: [New-bugs-announce] [issue45537] Cygwin is unsupported - close all
 open issues and list them here.
Message-ID: <1634731492.2.0.646251570361.issue45537@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

There isn't currently a maintainer for cpython on Cygwin, which by PEP 11 means it is no longer supported.

There are open issues (some with patches) from aborted attempts to support it in the past. They will be closed as duplicates of this issue, so that they can be easily accessible in the future in case someone commits to support Cygwin.

----------
messages: 404433
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Cygwin is unsupported - close all open issues and list them here.

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

From report at bugs.python.org  Wed Oct 20 08:35:32 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 20 Oct 2021 12:35:32 +0000
Subject: [New-bugs-announce] [issue45538] MinGW is unsupported - close all
 open issues and list them here.
Message-ID: <1634733332.39.0.633564936685.issue45538@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

There isn't currently a maintainer for cpython on MinGW, which by PEP 11 means it is not supported.

There are open issues (some with patches) from aborted attempts to support it in the past. They will be closed as duplicates of this issue, so that they can be easily accessible in the future in case someone commits to support MinGW.

----------
messages: 404439
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: MinGW is unsupported - close all open issues and list them here.

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

From report at bugs.python.org  Wed Oct 20 11:52:58 2021
From: report at bugs.python.org (Jirka Marsik)
Date: Wed, 20 Oct 2021 15:52:58 +0000
Subject: [New-bugs-announce] [issue45539] Negative lookaround assertions
 sometimes leak capture groups
Message-ID: <1634745178.86.0.213773355439.issue45539@roundup.psfhosted.org>


New submission from Jirka Marsik <jiri.marsik at oracle.com>:

When you have capture groups inside a negative lookaround assertion, the strings captured by those capture groups can sometimes survive the failure of the assertion and feature in the returned Match object.

Here it is illustrated with lookbehinds and lookaheads:

>>> re.search(r"(?<!(a)c)de", "abde").group(1)
'a'
>>> re.search(r"(?!(a)c)ab", "ab").group(1)
'a'

Even though the search for the expression '(a)c' fails when trying to match 'c', the string 'a' is still reported as having been successfully matched by capture group 1. The expected behavior would be for the capture group 1 to not have a match.

Because of the following reasons, I believe this behavior is not intentional and is the result of Python not cleaning up after the asserted subexpression fails (e.g. by running the asserted subexpression in a new stack frame).

1) This behavior is not being systematically enforced.
   We can observe this behavior only in certain cases. Modifying the expression to use the branching operator `|` inside the asserted subexpression leads to the expected behavior.

>>> re.search(r"(?<!(a)c|(a)d)de", "abde").group(1) is None
True
>>> re.search(r"(?!(a)c|(a)d)ab", "ab").group(1) is None
True

2) Other languages do not leak capture groups from negative lookarounds.

   Node.js (ECMAScript):

> /(?<!(a)c)de/.exec("abde")[1]
undefined
> /(?!(a)c)ab/.exec("ab")[1]
undefined
> /(?<!(a)c|(a)d)de/.exec("abde")[1]
undefined
> /(?!(a)c|(a)d)ab/.exec("ab")[1]
undefined

   MRI (Ruby):

irb(main):001:0> /(?<!(a)c)de/.match("abde")[1]
<unsupported>
irb(main):002:0> /(?!(a)c)ab/.match("ab")[1]
=> #<MatchData "ab" 1:nil>
irb(main):003:0> /(?<!(a)c|(a)d)de/.match("abde")[1]
<unsupported>
irb(main):004:0> /(?!(a)c|(a)d)ab/.match("ab")[1]
=> #<MatchData "ab" 1:nil 2:nil>

  JShell (Java):

jshell> Matcher m = java.util.regex.Pattern.compile("(?<!(a)c)de").matcher("abde")
jshell> m.find()
jshell> m.group(1)
$3 ==> null
jshell> Matcher m = java.util.regex.Pattern.compile("(?<!(a)c|(a)d)de").matcher("abde")
jshell> m.find()
jshell> m.group(1)
$6 ==> null
jshell> Matcher m = java.util.regex.Pattern.compile("(?!(a)c)ab").matcher("ab")
m ==> java.util.regex.Matcher[pattern=(?!(a)c)ab region=0,2 lastmatch=]
jshell> m.find()
jshell> m.group(1)
$9 ==> null
jshell> Matcher m = java.util.regex.Pattern.compile("(?!(a)c|(a)d)ab").matcher("ab")
m ==> java.util.regex.Matcher[pattern=(?!(a)c|(a)d)ab region=0,2 lastmatch=]
jshell> m.find()
jshell> m.group(1)
$12 ==> null

3) Not leaking capture groups from negative lookarounds is symmetric to how capture groups are treated in failed matches.
   When regular expression engines fail to match a regular expression, they do not provide a partial match object that contains the state of capture groups at the time when when the matcher failed. Instead, the state of the matcher is discarded and some bottom value is returned (None, null or undefined). Similarly, one would expect nested subexpressions to behave the same way, so that capture groups from failed match attempts are discarded.

----------
components: Regular Expressions
messages: 404479
nosy: ezio.melotti, jirkamarsik, mrabarnett
priority: normal
severity: normal
status: open
title: Negative lookaround assertions sometimes leak capture groups
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 20 13:11:23 2021
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Oct 2021 17:11:23 +0000
Subject: [New-bugs-announce] [issue45540] module.__package__ and
 module.__spec__.parent have different semantics
Message-ID: <1634749883.54.0.793446044283.issue45540@roundup.psfhosted.org>


New submission from Barry A. Warsaw <barry at python.org>:

TL;DR module.__spec__.parent is read-only but module.__package__ is r/w despite documentation that implies that these two attributes should be identical, and various issues that focus on migrating from direct module attributes to ModuleSpec attributes.

bpo-33277 and bpo-21762

Maybe we should relax the restriction on module.__spec__.parent so that it's writeable just like module.__package__.

See also: 

https://docs.python.org/3/reference/import.html?highlight=__loader__#package__

https://docs.python.org/3/library/types.html?highlight=__loader__#types.ModuleType.__package__

----------
components: Interpreter Core
messages: 404500
nosy: barry
priority: normal
severity: normal
status: open
title: module.__package__ and module.__spec__.parent have different semantics
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 20 13:18:31 2021
From: report at bugs.python.org (Lenin Kennedy)
Date: Wed, 20 Oct 2021 17:18:31 +0000
Subject: [New-bugs-announce] [issue45541] Broken Link in asyncio library Docs
Message-ID: <1634750311.24.0.287730141067.issue45541@roundup.psfhosted.org>


New submission from Lenin Kennedy <leninek24 at gmail.com>:

Priority: Low

In the asyncio page (https://docs.python.org/3/library/asyncio.html), 
in the bullet points of "set of high-level APIs to:", 

link to "perform network IO and IPC;" is (https://docs.python.org/3/library/asyncio-stream.html#asyncio-streams).

Here "#ayncio-streams" header does not exist.

Possible fix-
Change the hyperlink to (https://docs.python.org/3/library/asyncio-stream.html#streams)

----------
components: asyncio
messages: 404502
nosy: asvetlov, coderlens, yselivanov
priority: normal
severity: normal
status: open
title: Broken Link in asyncio library Docs
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 20 14:25:33 2021
From: report at bugs.python.org (Maja)
Date: Wed, 20 Oct 2021 18:25:33 +0000
Subject: [New-bugs-announce] [issue45542] Using multiple comparison
 operators can cause performance issues
Message-ID: <1634754333.52.0.650287816276.issue45542@roundup.psfhosted.org>


New submission from Maja <mavioko7 at gmail.com>:

For example:

    def f(x):
        return 1 < x < 3

will be slower than:

    def f(x):
        return 1 < x and x < 3

The first function will generate following bytecode:

              0 LOAD_CONST               1 (1)
              2 LOAD_FAST                0 (x)
              4 DUP_TOP
              6 ROT_THREE
              8 COMPARE_OP               0 (<)
             10 JUMP_IF_FALSE_OR_POP    18
             12 LOAD_CONST               2 (3)
             14 COMPARE_OP               0 (<)
             16 RETURN_VALUE
        >>   18 ROT_TWO
             20 POP_TOP
             22 RETURN_VALUE

Performs unnecessary stack operations: duplicates x, rotates 3 items for no reason, then re-rotates 2 items and pops a value. This is fine if the value in the middle was more complex and needed to be duplicated rather than recalculated, which would be definitely slower, but for simpler values like names or constants, it's actually bad. The bytecode for the first function should look the same as second one which is:

              0 LOAD_CONST               1 (1)
              2 LOAD_FAST                0 (x)
              4 COMPARE_OP               0 (<)
              6 JUMP_IF_TRUE_OR_POP     14
              8 LOAD_FAST                0 (x)
             10 LOAD_CONST               2 (3)
             12 COMPARE_OP               0 (<)
        >>   14 RETURN_VALUE

----------
components: Interpreter Core
messages: 404508
nosy: akuvfx
priority: normal
severity: normal
status: open
title: Using multiple comparison operators can cause performance issues
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 20 18:05:10 2021
From: report at bugs.python.org (Lee Bosch)
Date: Wed, 20 Oct 2021 22:05:10 +0000
Subject: [New-bugs-announce] [issue45543] IDLE shell Windows EOL <CR>
Message-ID: <1634767510.09.0.775917285757.issue45543@roundup.psfhosted.org>


New submission from Lee Bosch <harsh at harshness.net>:

The IDLE shell for Windows doesn't respect carriage returns in output strings.

When using a '\r' as sep, end or as part of the output strings, IDLE ignores it and I get linear output rather than each successive line printing over the previous output.  The same code works as expected in a conventional Windows shell (i.e. COMMAND).

----------
assignee: terry.reedy
components: IDLE
messages: 404530
nosy: harshness, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE shell Windows EOL <CR>
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 20 18:26:33 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 20 Oct 2021 22:26:33 +0000
Subject: [New-bugs-announce] [issue45544] Close 2to3 issues and list them
 here
Message-ID: <1634768793.61.0.522219525915.issue45544@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

2to3 is deprecated. All open issues will now being closed as duplicates of this issue, in case someone needs this list in the future.

----------
messages: 404531
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Close 2to3 issues and list them here

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

From report at bugs.python.org  Wed Oct 20 18:54:45 2021
From: report at bugs.python.org (Jeremy)
Date: Wed, 20 Oct 2021 22:54:45 +0000
Subject: [New-bugs-announce] [issue45545] chdir __exit__ is not safe
Message-ID: <1634770485.18.0.358610816486.issue45545@roundup.psfhosted.org>


New submission from Jeremy <ucodery at gmail.com>:

The way that contextlib.chdir currently restores the old working directory, an exception is raised if the program was already close to or beyond a system's PATH_MAX. The context manager has no issue crafting the path in __enter__ because os.getcwd() can return a path that is longer than PATH_MAX, but when used in __exit__ os.chdir() cannot use a path that long.

I think an __exit__ should be as cautious as possible to not raise as the exception can occur far away from where the context manager was created. Its also doesn't reflect the programmer actually using the context manager incorrectly as they might not have any control or care where the process was started, yet if it happened to already be at a deep path when launched, any use of chdir anywhere would cause exceptions.

I have tested this on macOS 11.13 using APFS but I am sure it would also fail on other macs and Linuxes. I don't know about Windows. Note I originally created this test as a patch to Lib/tests/test_contextlib.py but libregrtest uses os.getcwd() in its runner and that disrupts the traceback and misidentifies the cause of failure. Test file:

```python
import os
import shutil
from contextlib import chdir


def test_long_path():
    # NAME_MAX of 255
    long_filename = "_".join(["testdir"]*32)
    long_path_end = startingwd = os.getcwd()
    try:
        # I thought this would have to be 16, i.e. a path length over 4096, PATH_MAX
        # but seemingly just crossing 1050 is enough to fail
        for _ in range(4):
            os.mkdir(long_filename)
            os.chdir(long_filename)
            long_path_end = os.path.join(long_path_end, long_filename)
        os.mkdir(long_filename)
        long_path_end = os.path.join(long_path_end, long_filename)
        with chdir(long_filename):
            #self.assertEqual(os.getcwd(), long_path_end)
            assert os.getcwd() == long_path_end
            print("passed")
    finally:
        shutil.rmtree(os.path.join(startingwd, long_filename), ignore_errors=True)


test_long_path()
```

And output:
```
$ ./python.exe ./test_chdir.py
passed
Traceback (most recent call last):
  File "/Users/ucodery/git/cpython/./test_chdir.py", line 27, in <module>
    test_long_path()
    ^^^^^^^^^^^^^^^^
  File "/Users/ucodery/git/cpython/./test_chdir.py", line 19, in test_long_path
    with chdir(long_filename):
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ucodery/git/cpython/Lib/contextlib.py", line 781, in __exit__
    os.chdir(self._old_cwd.pop())
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 63] File name too long: '/Users/ucodery/git/cpython/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir'
```

----------
files: test_chdir.py
messages: 404534
nosy: ucodery
priority: normal
severity: normal
status: open
title: chdir __exit__ is not safe
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50377/test_chdir.py

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

From report at bugs.python.org  Wed Oct 20 19:12:50 2021
From: report at bugs.python.org (Eric Cousineau)
Date: Wed, 20 Oct 2021 23:12:50 +0000
Subject: [New-bugs-announce] [issue45546] Unable to pickle enum with nested
 frozen dataclass?
Message-ID: <1634771570.81.0.651443279732.issue45546@roundup.psfhosted.org>


New submission from Eric Cousineau <eric.cousineau at tri.global>:

I seem cannot pickle enum values from an enum class w/ a nested frozen dataclass.

I can pickle a field from a normal class w/ a nested frozen dataclass, and I can pickle a field from an enum with a top-level frozen dataclass - perhaps it's some interplay with `__qualname__` and `enum.py`?.

See attached file for sample test.
I checked on 3.6.9, 3.9.7, and 3.10.0.

Looked around, couldn't easily find existing issue for this.

----------
components: Library (Lib)
files: enum_test.py
messages: 404539
nosy: Eric Cousineau
priority: normal
severity: normal
status: open
title: Unable to pickle enum with nested frozen dataclass?
type: behavior
versions: Python 3.10, Python 3.6, Python 3.9
Added file: https://bugs.python.org/file50378/enum_test.py

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

From report at bugs.python.org  Wed Oct 20 19:15:10 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Wed, 20 Oct 2021 23:15:10 +0000
Subject: [New-bugs-announce] [issue45547] Modenize the importlib loaders
Message-ID: <1634771710.27.0.594592936094.issue45547@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

ResourceLoader[1] is deprecated in favor of ResourceReader, which itself is surpassed by TraversableResources.

Would it make sense to replace ResourceLoader usages with ResourceReader in the importlib loaders?
And perhaps, would it make sense to replace them with the files()/Traversable protocol instead?

IMO this could simplify the code a bit, but that's subjective I guess, and better re-use the bytecode caching mechanism in SourceLoader, by providing an equivalent based on files()/Traversable instead.

This could also help push to add support for non filesystem based loaders in other parts of the code, like py_compile, which currently only supports operations on the filesystem.

Is this something we are interested in -- modernizing the importlib loaders with, arguably, better abstractions -- or do we want to keep the old protocols around?

[1] https://docs.python.org/3/library/importlib.html#importlib.abc.ResourceLoader

----------
messages: 404540
nosy: FFY00, barry, brett.cannon, eric.snow, jaraco, ncoghlan
priority: normal
severity: normal
status: open
title: Modenize the importlib loaders

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

From report at bugs.python.org  Wed Oct 20 19:58:48 2021
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Oct 2021 23:58:48 +0000
Subject: [New-bugs-announce] [issue45548] Update Modules/Setup
Message-ID: <1634774328.21.0.335714426284.issue45548@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

`Modules/Setup` is currently incomplete/broken. Some things are completely missing from it, while others won't work if you uncomment them in the file.

When trying to compile a completely static CPython interpreter I ran into the following issues:

- _weakref is listed twice
- _testcapi can't be statically compiled
- math/cmath conflict with a build rule in Makefile.pre.in
- _dbm needs more logic/comments (at least on macOS)
- nis needs more logic/comments (at least on macOS)

And the following modules are completely missing from the file:
- _ctypes
- _decimal
- _lsprof
- _lzma
- _multiprocessing
- _opcode
- _posixshmem
- _queue
- _scproxy
- _sqlite3
- _testbuffer
- _testipmortmultiple
- _testmultiphase
- _uuid
- xxsubinterpreters
- xxtestfuzz
- ossaudiodev
- xxlimited
- xxlimited_35

----------
assignee: brett.cannon
components: Build
messages: 404548
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Update Modules/Setup
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 21 04:59:47 2021
From: report at bugs.python.org (Almog Mishraki)
Date: Thu, 21 Oct 2021 08:59:47 +0000
Subject: [New-bugs-announce] [issue45549] Seek in file object didn't treat
 all paths of exceptions
Message-ID: <1634806787.57.0.83503988126.issue45549@roundup.psfhosted.org>


New submission from Almog Mishraki <mog7599 at gmail.com>:

Hi
I detailed everything in the file I've upload.
Thanks in advanced

----------
components: Library (Lib)
files: Python - file Bug.txt
messages: 404573
nosy: mog7599
priority: normal
severity: normal
status: open
title: Seek in file object didn't treat all paths of exceptions
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/file50379/Python - file Bug.txt

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

From report at bugs.python.org  Thu Oct 21 06:16:53 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 21 Oct 2021 10:16:53 +0000
Subject: [New-bugs-announce] [issue45550] Increase the information content
 and robustness of tp_version_tag.
Message-ID: <1634811413.15.0.703765256195.issue45550@roundup.psfhosted.org>


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

Currently, we use the `tp_version_tag` as a proxy for the state of a class when specializing.
When we have issued 2**32 tags, we stop issuing tags. This prevents specializing of classes that need a new tag.

We can make a few enhancements:

1. Reserve the low 2**M (M probably 4 or 5) values for special classes. This would allow us to perform some type checks efficiently in a multiple-interpreter environment.
`PyLongCheck_Exact(ob)` is currently `Py_TYPE(ob) == &PyLong_Type` but could become `Py_TYPE(ob)->tp_version_tag == PY_INT_VERSION_TAG`. No need to access the interpreter state.

2. Reserve the low 2**N (N somewhere in range 10 to 16) for builtin classes. Maybe split this into immutable and mutable. 
We often need to load the version tag, this would save another load from tp_flags to check for builtin-ness and (im)mutability.

3. Add a modified count to the type struct. When this reaches a threshold, no longer issue tags for this class.
This would prevent pathological classes consuming millions of tags. Only needs 16 bits.

The reason we want power of two boundaries is so that we can test multiple types at once.
E.g. T1 and T2 are both "special" if `(T1->tp_version_tag | T2->tp_version_tag) < 2**M`

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 404580
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Increase the information content and robustness of tp_version_tag.
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 21 07:18:06 2021
From: report at bugs.python.org (Andrzej Kubaszek)
Date: Thu, 21 Oct 2021 11:18:06 +0000
Subject: [New-bugs-announce] [issue45551] EmailMessage utf-8 folding error
Message-ID: <1634815086.56.0.391780385462.issue45551@roundup.psfhosted.org>


New submission from Andrzej Kubaszek <kubaszek at prz.edu.pl>:

email.message - EmailMessage Error
Missing white space after folding on ','

msg['To'] = 'Ab ?<abc at def.com>,Ab ?<abc at def.com>,Ab ?<abc at def.com>,Ab ?<abc at def.com>'

print(msg.as_string())
'''
To: Ab =?utf-8?q?=C4=86?=<abc at def.com>,Ab =?utf-8?q?=C4=86?=<abc at def.com>,
Ab =?utf-8?q?=C4=86?=<abc at def.com>,Ab =?utf-8?q?=C4=86?=<abc at def.com>
Subject: EmailMessage Error. Missing white space after folding on ",".
 https://www.ietf.org/rfc/rfc2822.txt , 2.2.3. Long Header Fields
'''

----------
components: email
files: ERROR_folding_in_EmailMessage.py
messages: 404583
nosy: andrzejQ, barry, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage utf-8 folding error
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50380/ERROR_folding_in_EmailMessage.py

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

From report at bugs.python.org  Thu Oct 21 07:19:39 2021
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 21 Oct 2021 11:19:39 +0000
Subject: [New-bugs-announce] [issue45552] Close asyncore/asynchat/smtpd
 issues and list them here
Message-ID: <1634815179.56.0.671714542902.issue45552@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

asyncore/asynchat/smtpd are deprecated and will no longer be maintained. All open issues will now being closed with this as superseder, in case someone will need the list of those issues in the future.

----------
components: Library (Lib)
messages: 404584
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Close asyncore/asynchat/smtpd  issues and list them here

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

From report at bugs.python.org  Thu Oct 21 08:24:55 2021
From: report at bugs.python.org (NATANAEL PEIXOTO QUINTINO)
Date: Thu, 21 Oct 2021 12:24:55 +0000
Subject: [New-bugs-announce] [issue45553] The modules Scipy and Pandas don't
 install in Win11-64
Message-ID: <1634819095.45.0.569403158755.issue45553@roundup.psfhosted.org>


New submission from NATANAEL PEIXOTO QUINTINO <natanael.quintino at ppgi.ufrj.br>:

Hi, I would like to report that the scipy and pandas modules are not installing via pip module commands on Windows 11 64-bit. Thanks

----------
components: Extension Modules, Installation, Windows
messages: 404592
nosy: natanael.quintino, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: The modules Scipy and Pandas don't install in Win11-64
type: compile error
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Oct 21 09:05:12 2021
From: report at bugs.python.org (John Marshall)
Date: Thu, 21 Oct 2021 13:05:12 +0000
Subject: [New-bugs-announce] [issue45554] multiprocessing exitcode is
 insufficiently documented
Message-ID: <1634821512.68.0.19757436473.issue45554@roundup.psfhosted.org>


New submission from John Marshall <jmarshall at hey.com>:

<https://docs.python.org/3.11/library/multiprocessing.html#multiprocessing.Process.exitcode> describes exitcode as

"The child?s exit code. This will be None if the process has not yet terminated. A negative value -N indicates that the child was terminated by signal N."

and similarly in earlier documentation versions.

This does not describe what the exit code will be under normal circumstances, or if the child abends by raising a Python exception.

By examination of BaseProcess._bootstrap() it can be determined that the current behaviour appears to be:

* even if your subclass overrides the run() method, whatever this method returns is ignored (and in particular the return value has no effect on the child's exit code);

* if the run() method returns normally, the child's exit code will be 0;

* if the run() method raises SystemExit (or, I guess, calls sys.exit()) with an integer exit status, that exit status will be propagated to the child's exit code;

* if the run() method raises any other exception, the exception traceback will be printed to stderr and the child's exit code will be 1.


However I did not see a way to figure these details out from the documentation, and it is unclear whether all these details are supported behaviours.

----------
assignee: docs at python
components: Documentation
messages: 404597
nosy: docs at python, jmarshall
priority: normal
severity: normal
status: open
title: multiprocessing exitcode is insufficiently documented
type: behavior

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

From report at bugs.python.org  Thu Oct 21 10:54:42 2021
From: report at bugs.python.org (Matias G)
Date: Thu, 21 Oct 2021 14:54:42 +0000
Subject: [New-bugs-announce] [issue45555] Object stays alive for weak
 reference if an exception happens in constructor
Message-ID: <1634828082.31.0.276861942935.issue45555@roundup.psfhosted.org>


New submission from Matias G <guijarro at esrf.fr>:

Hi Python developers,

I stumbled on a weird behavior, which might be a bug actually.

I am surprised by the output of the following piece of code:

```
import weakref

refs = []

class A:
    def __init__(self):
        refs.append(weakref.ref(self))
        #raise RuntimeError() <<< enable this line of code and be surprised!

try:
    A()
finally:
    print(refs[0]())
```

The code prints None ; but, if the RuntimeError exception is raised
in the constructor, we find the object in the final print. It is not
dereferenced properly, as it seems:

```
<__main__.A object at 0x7f4b6cf23ed0>
Traceback (most recent call last):
  File "/tmp/test.py", line 11, in <module>
    A()
  File "/tmp/test.py", line 8, in __init__
    raise RuntimeError()
RuntimeError
```

I tried adding `gc.collect()` with no luck.

Am I doing something wrong ?

Thanks in advance

----------
components: Interpreter Core
messages: 404606
nosy: guijarro
priority: normal
severity: normal
status: open
title: Object stays alive for weak reference if an exception happens in constructor
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 21 11:03:58 2021
From: report at bugs.python.org (Mosquito)
Date: Thu, 21 Oct 2021 15:03:58 +0000
Subject: [New-bugs-announce] [issue45556] uuid.uuid4() fast optimization
Message-ID: <1634828638.25.0.268468778181.issue45556@roundup.psfhosted.org>


New submission from Mosquito <me at mosquito.su>:

I does a small experiment, and found out that if you generate UUID4 with int instead of sequence of bytes, then the generation of UUID4 occurs up to three times faster.

.. code-block: python

    import random
    import uuid

    print("uuid.uuid4()")
    %timeit uuid.uuid4()
    # 5.49 ?s ? 120 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

    print("uuid.UUID(int=random.getrandbits(128), version=4)")
    %timeit uuid.UUID(int=random.getrandbits(128), version=4)
    # 2.58 ?s ? 94.5 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)


I have already made fixes to my fork on GH, tell me, will it be useful to someone else besides me?

----------
components: Library (Lib)
files: 0001-Generating-uuid.uuid4-up-to-three-times-faster.patch
keywords: patch
messages: 404607
nosy: mosquito
priority: normal
severity: normal
status: open
title: uuid.uuid4() fast optimization
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file50381/0001-Generating-uuid.uuid4-up-to-three-times-faster.patch

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

From report at bugs.python.org  Thu Oct 21 15:48:33 2021
From: report at bugs.python.org (Jean-Philippe VINCENT)
Date: Thu, 21 Oct 2021 19:48:33 +0000
Subject: [New-bugs-announce] [issue45557] Issue 42914
In-Reply-To: <PA4PR10MB460504F41A228E63B286D427CDBF9@PA4PR10MB4605.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <PA4PR10MB4605A0C7BA64ECBA8555E00BCDBF9@PA4PR10MB4605.EURPRD10.PROD.OUTLOOK.COM>


New submission from Jean-Philippe VINCENT <jpvincent at hotmail.fr>:

Hello,

I just tried the new attribute underscore_numbers with pprint, it doesn't work for me. I'm working on Windows.

[cid:8779885d-01bf-4162-9427-a44de152f7ac]

Best regards,

Jean-Philippe

----------
files: image.png
messages: 404636
nosy: jpvincent
priority: normal
severity: normal
status: open
title: Issue 42914
Added file: https://bugs.python.org/file50385/image.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45557>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14926 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/new-bugs-announce/attachments/20211021/8aaa9a24/attachment.png>

From report at bugs.python.org  Thu Oct 21 16:20:18 2021
From: report at bugs.python.org (Doron Behar)
Date: Thu, 21 Oct 2021 20:20:18 +0000
Subject: [New-bugs-announce] [issue45558] shutil.copytree: Give the option
 to disable copystat
Message-ID: <1634847618.09.0.382160637693.issue45558@roundup.psfhosted.org>


Change by Doron Behar <doron.behar at gmail.com>:


----------
components: Library (Lib)
nosy: doronbehar
priority: normal
severity: normal
status: open
title: shutil.copytree: Give the option to disable copystat
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 21 16:23:04 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 21 Oct 2021 20:23:04 +0000
Subject: [New-bugs-announce] [issue45559] pprint module does not test
 pprint.pprint()
Message-ID: <1634847784.94.0.10912220069.issue45559@roundup.psfhosted.org>


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

For example, see issue 45557, where pprint.pformat(underscore_numbers=True) worked, but pprint.pprint(underscore_numbers=True) did not.

Testing of pprint.pprint() should be added.

----------
components: Library (Lib)
messages: 404647
nosy: eric.smith
priority: normal
severity: normal
status: open
title: pprint module does not test pprint.pprint()
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Oct 21 17:31:52 2021
From: report at bugs.python.org (Andre Roberge)
Date: Thu, 21 Oct 2021 21:31:52 +0000
Subject: [New-bugs-announce] [issue45560] sys.last_* not set for
 SyntaxErrors with IDLE
Message-ID: <1634851912.62.0.543698979656.issue45560@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

As stated in the documentation, sys.last_type, sys.last_value and sys.last_traceback ... are set when an exception is not handled and the interpreter prints an error message and a stack traceback.

This is true whether the exception is a SyntaxError or some runtime error when a standard Python interpreter is used.

However, when the IDLE shell is used and a SyntaxError occurs, these are not set.  If it is not possible to change this behaviour in IDLE, perhaps the documentation of the sys module should be amended to include this information.

----------
assignee: terry.reedy
components: IDLE
messages: 404669
nosy: aroberge, terry.reedy
priority: normal
severity: normal
status: open
title: sys.last_* not set for SyntaxErrors with IDLE
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/issue45560>
_______________________________________

From report at bugs.python.org  Thu Oct 21 17:38:00 2021
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 21 Oct 2021 21:38:00 +0000
Subject: [New-bugs-announce] [issue45561] Run smelly.py and multissltests.py
 from $(srcdir)
Message-ID: <1634852280.03.0.00103137600776.issue45561@roundup.psfhosted.org>


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

Some makefile rules don't work if you build in a separate folder.

----------
messages: 404671
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: Run smelly.py and multissltests.py from $(srcdir)
type: behavior

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

From report at bugs.python.org  Thu Oct 21 17:54:15 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Oct 2021 21:54:15 +0000
Subject: [New-bugs-announce] [issue45562] python -d creates lots of
 tokenizer messages
Message-ID: <1634853255.49.0.658081837548.issue45562@roundup.psfhosted.org>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

python3.9 -d:

Python 3.9.7 (default, Oct 21 2021, 20:51:19)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
Loaded pyinteractive.py.

>>>

python3.10 -d:

Python 3.10.0 (default, Oct 21 2021, 23:13:32) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
line[1] = "\"\"\" pyinteractive.py\n"  tok->done = 10
line[2] = "\n"  tok->done = 10
line[3] = "    This file is executed on interactive startup by Python\n"  tok->done = 10
...

(not that in both cases a PYTHONINTERACTIVE script is loaded)

Is that intended ?

----------
messages: 404673
nosy: lemburg
priority: normal
severity: normal
status: open
title: python -d creates lots of tokenizer messages
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 21 18:02:12 2021
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Oct 2021 22:02:12 +0000
Subject: [New-bugs-announce] [issue45563] inspect.getframeinfo() doesn't
 handle frames without lineno
Message-ID: <1634853732.41.0.89193081236.issue45563@roundup.psfhosted.org>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

In Python 3.10, it seems that top-level frames generated by running exec() have their f_lineno attribute set to None.

inspect.getframeinfo() tries to build context lines and fails on this line in such a case:

        start = lineno - 1 - context//2

because lineno is None.

It's not clear whether this is a bug in inspect or the way such frames get their f_lineno attribute initialized.

The same code works just fine in Python 3.9.

----------
messages: 404674
nosy: lemburg
priority: normal
severity: normal
status: open
title: inspect.getframeinfo() doesn't handle frames without lineno
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 21 18:21:02 2021
From: report at bugs.python.org (Alexander Patrakov)
Date: Thu, 21 Oct 2021 22:21:02 +0000
Subject: [New-bugs-announce] [issue45564] shutil.rmtree and os.walk are
 implemented using recursion, fail on deep hierarchies
Message-ID: <1634854862.16.0.108410950384.issue45564@roundup.psfhosted.org>


New submission from Alexander Patrakov <patrakov at gmail.com>:

It is possible to create deep directory hierarchies that cannot be removed via shutil.rmtree or walked via os.walk, because these functions exceed the interpreter recursion limit. This may have security implications for web services (e.g. various webdisks) that have to clean up user-created mess or walk through it.

[aep at aep-haswell ~]$ mkdir /tmp/badstuff
[aep at aep-haswell ~]$ cd /tmp/badstuff
[aep at aep-haswell badstuff]$ for x in `seq 2048` ; do mkdir $x ; cd $x ; done
[aep at aep-haswell 103]$ cd
[aep at aep-haswell ~]$ python
Python 3.9.7 (default, Oct 10 2021, 15:13:22) 
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.rmtree('/tmp/badstuff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/shutil.py", line 726, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  [Previous line repeated 992 more times]
  File "/usr/lib/python3.9/shutil.py", line 642, in _rmtree_safe_fd
    fullname = os.path.join(path, entry.name)
  File "/usr/lib/python3.9/posixpath.py", line 77, in join
    sep = _get_sep(a)
  File "/usr/lib/python3.9/posixpath.py", line 42, in _get_sep
    if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object
>>> import os
>>> list(os.walk('/tmp/badstuff'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/os.py", line 418, in _walk
    yield from _walk(new_path, topdown, onerror, followlinks)
  File "/usr/lib/python3.9/os.py", line 418, in _walk
    yield from _walk(new_path, topdown, onerror, followlinks)
  File "/usr/lib/python3.9/os.py", line 418, in _walk
    yield from _walk(new_path, topdown, onerror, followlinks)
  [Previous line repeated 993 more times]
  File "/usr/lib/python3.9/os.py", line 412, in _walk
    new_path = join(top, dirname)
  File "/usr/lib/python3.9/posixpath.py", line 77, in join
    sep = _get_sep(a)
  File "/usr/lib/python3.9/posixpath.py", line 42, in _get_sep
    if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object
>>>

----------
components: Library (Lib)
messages: 404687
nosy: Alexander.Patrakov
priority: normal
severity: normal
status: open
title: shutil.rmtree and os.walk are implemented using recursion, fail on deep hierarchies
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 22 03:15:31 2021
From: report at bugs.python.org (Ken Jin)
Date: Fri, 22 Oct 2021 07:15:31 +0000
Subject: [New-bugs-announce] [issue45565] More LOAD_ATTR specializations
Message-ID: <1634886931.96.0.742375847346.issue45565@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
components: Interpreter Core
nosy: Mark.Shannon, kj
priority: normal
severity: normal
status: open
title: More LOAD_ATTR specializations
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 22 04:39:07 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 22 Oct 2021 08:39:07 +0000
Subject: [New-bugs-announce] [issue45566] `test_frozen_pickle` does not use
 all possible `pickle` protocols
Message-ID: <1634891947.06.0.600142901544.issue45566@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

While working on https://github.com/python/cpython/pull/29147 I've noticed that `test_frozen_pickle` does not use all possible `pickle` protocols: https://github.com/python/cpython/blob/276468dddb46c54980c782c09cdb53bd90755752/Lib/test/test_dataclasses.py#L2862

I will add `for` and `self.subTest` for each unique `pickle` protocol.
After that it would be in sync with `3.9` branch.

----------
components: Tests
messages: 404728
nosy: sobolevn
priority: normal
severity: normal
status: open
title: `test_frozen_pickle` does not use all possible `pickle` protocols
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Oct 22 04:59:46 2021
From: report at bugs.python.org (Hans-Christoph Steiner)
Date: Fri, 22 Oct 2021 08:59:46 +0000
Subject: [New-bugs-announce] [issue45567] Support TLS Encrypted ClientHello
 (ECH)
Message-ID: <1634893186.6.0.527110144987.issue45567@roundup.psfhosted.org>


New submission from Hans-Christoph Steiner <hans at eds.org>:

The next version of the IETF-standardized TLS protocol is known as Encrypted ClientHello (ECH) [1] formerly known as Encrypted SNI (ESNI). This ticket collects information for ECH support, and tracks which APIs have to be added to Python in order to implement ECH in Python's ssl module.  ECH is built on top of TLSv1.3 and completes the unfinished work from the TLSv1.3 effort.  It is now in draft-13 and there are many implementations that are interoperating.  ECH is working for openssl[2], boringssl[3], nginx, Apache HTTPD, lighttpd, HAProxy, Conscrypt[4], curl, and more.  There is work underway in Firefox [5] and Chromium [6].  It has been sketched out for OkHTTP [7].  Early versions of the standard, known as ESNI, have been deployed in Firefox releases and some production web services.  ECH works in conjunction with the new DNS RR Types HTTPS and SVCB [8].  This means that DNS needs to be handled a bit differently.

As far as I understand it, the ssl module has to gain additional features:

1. HTTPS/SVCB DNS queries for setting up TLS connection with ECH.
2. A way to provide ECH Config Lists as bytes directly to ssl clients.
3. A callback that gets called whenever ECH negotiation fails and the server offers a "Retry Config".
4. A method to ensure encrypted DNS is used so all metadata is encrypted.

OpenSSL does not implement the necessary APIs yet. Stephen Farrell's development OpenSSL fork [9] implements ECH and has been used in Apache HTTPD, nginx, lighttpd, HAProxy, and curl implementations.

The TLS WG maintain a page with information about other implementations:
https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementations


[1] https://www.ietf.org/archive/id/draft-ietf-tls-esni-13.html
[2] https://github.com/openssl/openssl/issues/7482
[3] https://bugs.chromium.org/p/boringssl/issues/detail?id=275
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1725938
[6] https://bugs.chromium.org/p/chromium/issues/detail?id=1091403
[6] https://github.com/google/conscrypt/issues/730
[7] https://github.com/square/okhttp/issues/6539
[8] https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.html
[9] https://github.com/sftcd/openssl

----------
assignee: christian.heimes
components: SSL
messages: 404732
nosy: christian.heimes, eighthave
priority: normal
severity: normal
status: open
title: Support TLS Encrypted ClientHello (ECH)
type: enhancement

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

From report at bugs.python.org  Fri Oct 22 05:51:42 2021
From: report at bugs.python.org (Zbigniew Siciarz)
Date: Fri, 22 Oct 2021 09:51:42 +0000
Subject: [New-bugs-announce] [issue45568] @asynccontextmanager is missing in
 decorator usage example
Message-ID: <1634896302.66.0.162029203149.issue45568@roundup.psfhosted.org>


New submission from Zbigniew Siciarz <zbigniew at siciarz.net>:

The docs of contextlib.asynccontextmanager provide an example how to use it as a decorator (https://docs.python.org/3/library/contextlib.html#contextlib.asynccontextmanager). However, the example snippet of code doesn't decorate the timeit() function with @asynccontextmanager, leading to reader confusion.

----------
assignee: docs at python
components: Documentation
messages: 404739
nosy: docs at python, zsiciarz
priority: normal
severity: normal
status: open
title: @asynccontextmanager is missing in decorator usage example
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 22 06:21:47 2021
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Oct 2021 10:21:47 +0000
Subject: [New-bugs-announce] [issue45569] Drop support for 15-bit PyLong
 digits?
Message-ID: <1634898107.47.0.88725686674.issue45569@roundup.psfhosted.org>


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

Looking at issue #35037 (which is a compatibility issue having to do with PYLONG_BITS_IN_DIGIT), I'm wondering whether it would make sense to drop support for 15-bit PyLong digits altogether. This would simplify some of the code, eliminate a configuration option, and eliminate the scope for ABI mismatches like that occurring in #35037.

There were a couple of reasons that we kept support for 15-bit digits when 30-bit digits were introduced, back in #4258.

- At the time, we wanted to use `long long` for the `twodigits` type with 30-bit digits, and we couldn't guarantee that all platforms we cared about would have `long long` or another 64-bit integer type available.

- It wasn't clear whether there were systems where using 30-bit digits in place of 15-bit digits might cause a performance regression.

Now that we can safely rely on C99 support on all platforms we care about, the existence of a 64-bit integer type isn't an issue (and indeed, we already rely on the existence of such a type in dtoa.c and elsewhere in the codebase).

As to performance, I doubt that there are still platforms where using 15-bit digits gives a performance advantage, but I admit I haven't checked.

----------
messages: 404746
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Drop support for 15-bit PyLong digits?

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

From report at bugs.python.org  Fri Oct 22 08:40:23 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Oct 2021 12:40:23 +0000
Subject: [New-bugs-announce] [issue45570] Simplify setup macros for pyexpat
 and _elementtree
Message-ID: <1634906423.38.0.044839571581.issue45570@roundup.psfhosted.org>


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

setup.py and Modules/Setup define a couple of macros for pyexpat and _elementtree. The macros are no longer needed or should be moved to our expat_config.h copy.

* HAVE_EXPAT_CONFIG_H is not used by our code and not used by system-wide expat header files
* USE_PYEXPAT_CAPI is no longer used by our code
* XML_POOR_ENTROPY should be defined in expat_config.h

----------
assignee: christian.heimes
components: Build
messages: 404761
nosy: brett.cannon, christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: Simplify setup macros for pyexpat and _elementtree
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 22 09:21:54 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Oct 2021 13:21:54 +0000
Subject: [New-bugs-announce] [issue45571] Modules/makesetup uses wrong
 CFLAGS for *shared*
Message-ID: <1634908914.03.0.439923093863.issue45571@roundup.psfhosted.org>


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

I think that makesetup uses the wrong CFLAGS variable for shared modules. The script uses PY_CFLAGS:

    no)     cc="$cc \$(CCSHARED) \$(PY_CFLAGS) \$(PY_CPPFLAGS)";;

while setup.py uses PY_CFLAGS_NODIST:

    set_compiler_flags('CFLAGS', 'PY_CFLAGS_NODIST')

The flags are similar but not equal. Amongst others PY_CFLAGS does not include Include/internal while PY_CFLAGS_NODIST has -I./Include/internal.

----------
components: Build
messages: 404766
nosy: brett.cannon, christian.heimes, twouters, vstinner
priority: normal
severity: normal
status: open
title: Modules/makesetup uses wrong CFLAGS for *shared*
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct 22 09:35:34 2021
From: report at bugs.python.org (tongxiaoge)
Date: Fri, 22 Oct 2021 13:35:34 +0000
Subject: [New-bugs-announce] [issue45572] urllib.request:AttributeError:
 'dict' object has no attribute 'get_all' in http_error_auth_reqed function
Message-ID: <1634909734.24.0.124969342817.issue45572@roundup.psfhosted.org>


New submission from tongxiaoge <shixuantong at huawei.com>:

The python version I currently use in my development environment is 3.7.4. Using the following script, the program has never output, and seems to have entered an infinite loop.

To reproduce the issue we can use the following code:

from urllib.request import AbstractBasicAuthHandler
auth_handler = AbstractBasicAuthHandler()
header = {'www-authenticate': 'Basic ' + ',' * 64 + ' ' + 'foo' + ' ' +'realm'}
auth_handler.http_error_auth_reqed('www-authenticate','unused','unused',header)




So I tried to upgrade it to version 3.7.12, and the program will directly report an error. The information is as follows:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/urllib/request.py", line 990, in http_error_auth_reqed
    headers = headers.get_all(authreq)
AttributeError: 'dict' object has no attribute 'get_all'

This problem also exists when I upgrade Python 3 to 3.11.0a1. In Python version 3.7.4, the cause of program hang on seems to be a security vulnerability. Refer to https://bugs.python.org/issue39503. The reason for CVE is not the wrong type of headers. However, after repairing CVE, it seems that the type of headers is limited? For the CVE patch, I tried to only fix the part of the regular expression, and the program can run. So, after repairing CVE-2020-8492, what type should the headers parameter be for http_error_auth_reqed  function? Based on the current code, how should I adapt and modify it to make it run normally?

----------
components: Library (Lib)
files: 3.7.4 hang on.png
messages: 404767
nosy: sxt1001
priority: normal
severity: normal
status: open
title: urllib.request:AttributeError: 'dict' object has no attribute 'get_all' in http_error_auth_reqed function
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50386/3.7.4 hang on.png

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

From report at bugs.python.org  Fri Oct 22 11:22:43 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Oct 2021 15:22:43 +0000
Subject: [New-bugs-announce] [issue45573] Use pkg-config autoconf macros to
 detect flags for Modules/Setup
Message-ID: <1634916163.65.0.792026628337.issue45573@roundup.psfhosted.org>


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

pkg-config [1] is a standard tool on Linux and other platforms to detect presence of dependencies as well as to figure out which compiler and linker flags they require. Development packages provide a .pc file, e.g. ncurses provides a ncursesw.pc file.

$ pkg-config --libs --cflags ncursesw
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -lncursesw -ltinfo

I propose to use a modified version of pkg-config's PKG_HAVE_DEFINE_WITH_MODULES macro in our configure script. On succss the modified macro defines:

* HAVE_FOO=1
* FOO_CFLAGS="some compile flags"
* FOO_LIBS="some library flags for linker"

On error, it sets nothing and does not cause configure to stop with an error.

The macro also allows users to override flags by setting FOO_CFLAGS and FOO_LIBS env vars. HAVE_FOO is added to pyconfig.h. The FOO_CFLAGS/LIBS are added to Makefile, from where it can be consumed by Modules/Setup.

Eventually Python could use the flags in setup.py, too. For now I would like to start with Modules/Setup. It is only used by some power users and has less risk of breaking the setup of beginners.

[1] https://www.freedesktop.org/wiki/Software/pkg-config/

----------
assignee: christian.heimes
components: Build
messages: 404781
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Use pkg-config autoconf macros to detect flags for Modules/Setup
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 22 11:42:43 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 22 Oct 2021 15:42:43 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue45574=5D_Warning=3A_?=
 =?utf-8?b?4oCYcHJpbnRfZXNjYXBl4oCZIGRlZmluZWQgYnV0IG5vdCB1c2Vk?=
Message-ID: <1634917363.52.0.444019325273.issue45574@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Recently, GitHub started to show a new warning:

> Check warning on line 999 in Parser/tokenizer.c
> GitHub Actions / Address sanitizer
> Parser/tokenizer.c#L999
> ?print_escape? defined but not used [-Wunused-function]

Link: https://github.com/python/cpython/pull/29158/files#file-parser-tokenizer-c-L999

I guess this happens because `print_escape` is only used when `Py_DEBUG` is set:

```
#if defined(Py_DEBUG)
        if (Py_DebugFlag) {
            printf("line[%d] = ", tok->lineno);
            print_escape(stdout, tok->cur, tok->inp - tok->cur);
            printf("  tok->done = %d\n", tok->done);
        }
#endif
```

Will this be a proper fix? Or do we need it for some other reason?

```
#if defined(Py_DEBUG)
static void
print_escape(FILE *f, const char *s, Py_ssize_t size)
// ...
# endif
```

If it's fine, I will send a PR :)

----------
messages: 404786
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Warning: ?print_escape? defined but not used

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

From report at bugs.python.org  Fri Oct 22 12:20:28 2021
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 22 Oct 2021 16:20:28 +0000
Subject: [New-bugs-announce] [issue45575] Use a more principled approach to
 freelists
Message-ID: <1634919628.65.0.571286636454.issue45575@roundup.psfhosted.org>


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

We have multiple freelists for performance, but they are adhoc and poorly integrated with the underlying allocator.

Improving this should give us a decent speedup.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 404788
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Use a more principled approach to freelists
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 22 12:40:33 2021
From: report at bugs.python.org (Luis Franca)
Date: Fri, 22 Oct 2021 16:40:33 +0000
Subject: [New-bugs-announce] [issue45576] Cannot import modules from Zip64
 files
Message-ID: <1634920833.59.0.789504609207.issue45576@roundup.psfhosted.org>


New submission from Luis Franca <lfamorim at gmail.com>:

I've tried to import a module from a fat jar file and got a ModuleNotFoundError: No module named ... error.

I checked that the jar file had more than 65k files and was created using Zip64. When I unzip the file, Python is capable of importing the modules.

I was able to reproduce the error on a simple project, such as:

simplePackage/
  __init__.py
  a/
    __init__.py
    moduleA.py

where

- I'm using Python 3.9.4
- __init__.py files are empty
- moduleA.py only has a printA() function

I ran the following tests:

1. When importing from the folder, it works

python
>>> import sys
>>> sys.path.append('C:\\Users\\...\\simplePackage')
>>> from a.moduleA import printA
>>> printA()
I'm module a

2. When zipping the folder, it works

python
>>> import sys
>>> sys.path.append('C:\\Users\\...\\simplePackage.zip')
>>> from a.moduleA import printA
>>> printA()
I'm module a

3. When forcing to zip with Zip64 it doesn't work

On linux: zip -fzr simple64Package.zip .

python
>>> import sys
>>> sys.path.append('C:\\Users\\...\\simple64Package.zip')
>>> from a.moduleA import printA
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'a'

Is this an expected behavior? Am I missing something?

Thanks!

----------
components: Library (Lib)
messages: 404792
nosy: lfamorim
priority: normal
severity: normal
status: open
title: Cannot import modules from Zip64 files
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 22 12:42:30 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 22 Oct 2021 16:42:30 +0000
Subject: [New-bugs-announce] [issue45577] Make `test_zoneinfo.py` to check
 all pickle protocols
Message-ID: <1634920950.64.0.966445570701.issue45577@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Right now it only uses a default one.

Examples:
- `3.9`: https://github.com/python/cpython/blob/aa8c3446c085175e65e736b0d2e32719c00004d2/Lib/test/test_zoneinfo/test_zoneinfo.py#L1407
- `3.10`: https://github.com/python/cpython/blob/ae78ffdc9399802621eabcd1668e44a91ec5f45e/Lib/test/test_zoneinfo/test_zoneinfo.py#L1407
- `main`: https://github.com/python/cpython/blob/ec93721e0066c4cbe40085188a9bf0952aa935ef/Lib/test/test_zoneinfo/test_zoneinfo.py#L1405

PR is on its way!

----------
components: Tests
messages: 404793
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Make `test_zoneinfo.py` to check all pickle protocols
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct 22 14:15:58 2021
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 22 Oct 2021 18:15:58 +0000
Subject: [New-bugs-announce] [issue45578] Missing tests for he dis module
Message-ID: <1634926558.7.0.911953252083.issue45578@roundup.psfhosted.org>


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

I don't see any tests for the following:

dis.distb
dis.findlabels

They are documented, I wonder if it was intentional.

dis.findlabels is also not dicumented.

----------
components: Tests
messages: 404805
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Missing tests for he dis module
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 22 14:55:25 2021
From: report at bugs.python.org (TL)
Date: Fri, 22 Oct 2021 18:55:25 +0000
Subject: [New-bugs-announce] [issue45579] [list.append(i) for i in list]
 causes high resources usage
Message-ID: <1634928925.4.0.945346089321.issue45579@roundup.psfhosted.org>


New submission from TL <tls.tuxla at gmail.com>:

Version:
Python 3.10.0 - Windows 11 (22000.258) x64
Python 3.9.7 - Windows 11, Manjaro Linux 21.1.5 - Kernel 5.13.13-1-MANJARO x64
CPU: 8 ? Intel? Core? i5-8300H CPU @ 2.30GHz

Steps to reproduce:
1. Create any list, for example your_list = [1, 2, 3]
2. Execute [your_list.append(i) for i in your_list]

----------
components: Interpreter Core
messages: 404813
nosy: txlbr
priority: normal
severity: normal
status: open
title: [list.append(i) for i in list] causes high resources usage
type: resource usage
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Oct 22 15:31:30 2021
From: report at bugs.python.org (AbcSxyZ)
Date: Fri, 22 Oct 2021 19:31:30 +0000
Subject: [New-bugs-announce] [issue45580]
 argparse.ArgumentParser.add_mutually_exclusive_group : metavar create
 parenthesis undefined behavior
Message-ID: <1634931090.99.0.410236903356.issue45580@roundup.psfhosted.org>


New submission from AbcSxyZ <rossi.sim at outlook.com>:

Hi,

I'm getting a kind of undefined behavior where parenthesis seem handled in a strange way. On display, it has a conflict between parenthesis of the option, and nested parenthesis within a metavar.

##?Reproduction script

```
import argparse

def main():
    parser = argparse.ArgumentParser()

    group = parser.add_mutually_exclusive_group(required=True)

    group.add_argument("-p", "--path", metavar="/var/www/html", 
            help="DocumentRoot path")
    group.add_argument("-r", "--reverse", metavar="http)s(://Host:Port",
            help="Reverse proxy address")

    parser.add_argument("--last-args")
    return parser.parse_args()

main()
```

##?Output of help menu
```
usage: crash.py [-h] (-p /var/www/html | -r http)s://Host:Port [--last-args LAST_ARGS]
```

## Expected behavior
```
usage: crash.py [-h] (-p /var/www/html | -r http)s(://Host:Port) [--last-args LAST_ARGS]
```

----------
components: Parser
messages: 404815
nosy: AbcSxyZ, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser.add_mutually_exclusive_group : metavar create parenthesis undefined behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 22 15:42:51 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 22 Oct 2021 19:42:51 +0000
Subject: [New-bugs-announce] [issue45581] [sqlite3] raise MemoryError if
 sqlite3_open_v2() returns SQLITE_NOMEM
Message-ID: <1634931771.8.0.677146859676.issue45581@roundup.psfhosted.org>


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

Currently, we call _pysqlite_seterror() if sqlite3_open_v2() returns != SQLITE_OK. However, if a memory failure occurs during sqlite3_open_v2(), the database handle is explicitly set to NULL. This _may_ cause _pysqlite_seterror() to segfault, since we pass it a NULL db pointer, because behaviour is undefined if we pass sqlite3_errmsg() a NULL pointer.


See also:
- https://sqlite.org/c3ref/open.html

----------
assignee: erlendaasland
components: Extension Modules
messages: 404818
nosy: erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] raise MemoryError if sqlite3_open_v2() returns SQLITE_NOMEM
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct 22 19:26:55 2021
From: report at bugs.python.org (Steve Dower)
Date: Fri, 22 Oct 2021 23:26:55 +0000
Subject: [New-bugs-announce] [issue45582] Rewrite getpath.c in Python
Message-ID: <1634945215.33.0.141600213082.issue45582@roundup.psfhosted.org>


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

As discussed in issue42260, combining the two getpath implementations into a single Python implementation would make it more maintainable and modifiable (particularly where distros need to patch to support alternative layouts).

----------
assignee: steve.dower
components: Interpreter Core
messages: 404841
nosy: eric.snow, ncoghlan, steve.dower, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Rewrite getpath.c in Python
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 22 20:40:05 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Sat, 23 Oct 2021 00:40:05 +0000
Subject: [New-bugs-announce] [issue45583] Documentation of int() in
 datamodel.rst is out of date
Message-ID: <1634949605.24.0.0641435404763.issue45583@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

In 3.8, int() default implementation changed, using __index__() if it is available instead of __trunc__(). The file function.rst was updated accordingly, but the redundant information in datamodel.rst contained out of date information

I offer a correction in https://github.com/python/cpython/pull/29182 (but ideally it should be added back to 3.8 python documentation)

----------
assignee: docs at python
components: Documentation
messages: 404848
nosy: ArthurMilchior, docs at python
priority: normal
severity: normal
status: open
title: Documentation of int() in datamodel.rst is out of date
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 22 21:31:06 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Sat, 23 Oct 2021 01:31:06 +0000
Subject: [New-bugs-announce] [issue45584] Clarifying truncating in
 documentation
Message-ID: <1634952666.85.0.640050968697.issue45584@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

While floor/ceil 's documentation are very precise, `truncate` was not explained. I actually had to search online to understand the difference between `truncate` and `floor` (admittedly, once I remembered that numbers are signed, and that floating numbers actually uses a bit for negation symbol instead of two complement, it became obvious)

I assume that I won't be the only user having this trouble, especially for people whose mother tongue is not English. So I suggest adding a clarification to help make what should be obvious to most actually explicit

----------
assignee: docs at python
components: Documentation
messages: 404850
nosy: ArthurMilchior, docs at python
priority: normal
severity: normal
status: open
title: Clarifying truncating in documentation
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/issue45584>
_______________________________________

From report at bugs.python.org  Sat Oct 23 02:13:57 2021
From: report at bugs.python.org (Michael Herrmann)
Date: Sat, 23 Oct 2021 06:13:57 +0000
Subject: [New-bugs-announce] [issue45585] Gzipping subprocess output
 produces invalid .gz file
Message-ID: <1634969637.88.0.109314303688.issue45585@roundup.psfhosted.org>


New submission from Michael Herrmann <mherrmann.at at gmail.com>:

Consider the following:

import gzip
import subprocess

with gzip.open('test.gz', 'wb') as f:
    subprocess.run(['echo', 'hi'], stdout=f)

with gzip.open('test.gz', 'rb') as f:
    print(f.read())

I'd expect "hi" to appear in my console. Instead, I'm getting "OSError: Not a gzipped file (b'hi')". I am attaching test.gz.

This appears for me on Debian 10 / Python 3.7 and Debian 11 / Python 3.9. I have not yet tested on other OSs and Python versions.

The reason why I expect the above to work is that the subprocess documentation states that the stdout parameter may be "an existing file object" and that on the other hand the documentation for gzip.open(...) states that it returns a file object.

Maybe this is related to #40885?

----------
files: test.gz
messages: 404853
nosy: mherrmann.at
priority: normal
severity: normal
status: open
title: Gzipping subprocess output produces invalid .gz file
type: behavior
versions: Python 3.7, Python 3.9
Added file: https://bugs.python.org/file50391/test.gz

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

From report at bugs.python.org  Sat Oct 23 04:58:24 2021
From: report at bugs.python.org (Peter Tillema)
Date: Sat, 23 Oct 2021 08:58:24 +0000
Subject: [New-bugs-announce] [issue45586] Use starred expressions in list
 indices
Message-ID: <1634979504.27.0.148840399936.issue45586@roundup.psfhosted.org>


New submission from Peter Tillema <petertillema at solcon.nl>:

It would be nice if you could starred expressions in list indices, for example this piece of code:

```
import numpy as np

a = np.array(0)
print(a[1, *[2, 3], 4])
```

----------
components: Interpreter Core
messages: 404860
nosy: PeterTillema
priority: normal
severity: normal
status: open
title: Use starred expressions in list indices
versions: Python 3.10

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

From report at bugs.python.org  Sat Oct 23 08:43:40 2021
From: report at bugs.python.org (SelfAdjointOperator)
Date: Sat, 23 Oct 2021 12:43:40 +0000
Subject: [New-bugs-announce] [issue45587] argparse add_argument_group:
 distinguish title and description from **kwargs
Message-ID: <1634993020.24.0.371084360422.issue45587@roundup.psfhosted.org>


Change by SelfAdjointOperator <jayberry141 at gmail.com>:


----------
assignee: docs at python
components: Documentation, Library (Lib)
nosy: SelfAdjointOperator, docs at python
priority: normal
severity: normal
status: open
title: argparse add_argument_group: distinguish title and description from **kwargs
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Oct 23 08:50:45 2021
From: report at bugs.python.org (Marten Lienen)
Date: Sat, 23 Oct 2021 12:50:45 +0000
Subject: [New-bugs-announce] [issue45588] cached_method similar to
 cached_property to cache with classes
Message-ID: <1634993445.55.0.469846719114.issue45588@roundup.psfhosted.org>


New submission from Marten Lienen <marten.lienen at gmail.com>:

There should be a `cached_method` equivalent to `cached_property` so that methods of long-lived objects can be cached easily.

----------
components: Library (Lib)
messages: 404870
nosy: martenlienen
priority: normal
severity: normal
status: open
title: cached_method similar to cached_property to cache with classes
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Oct 23 13:33:22 2021
From: report at bugs.python.org (Guido F)
Date: Sat, 23 Oct 2021 17:33:22 +0000
Subject: [New-bugs-announce] [issue45589] webbrowser does not handle opens
 under Windows WSL properly
Message-ID: <1635010402.44.0.770979979986.issue45589@roundup.psfhosted.org>


New submission from Guido F <guido.fioravantti at gmail.com>:

The 'webbrowser' module throws warnings and bad RC codes when running under Windows Subsystem for Linux (WSL).

This causes libraries that depend on the 'webbrowser' module to mistakenly assume there's been an error opening a URL. An example of this behaviour can be observed running `jupyter-lab` under WSL.

Steps to reproduce:
1. Run Ubuntu (for example) under Windows WSL.
2. `python -m webbrowser https://www.python.org`

Expected result:

The wesite opens.

Actual result:

The website opens but produces a `No valid TTY` message, which also yields a non-zero return code.

I have a patch for this bug that inspects the kernel version (platform.uname) and detects WSL. This is a similar solution that other projects have implemented to tackle this problem. For example, the fish shell project: https://github.com/fish-shell/fish-shell/blob/0e06a53dff5e198c4fcefb6419a53cf1267231a1/share/functions/help.fish#L83.

----------
components: Windows
messages: 404896
nosy: guido.fioravantti, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: webbrowser does not handle opens under Windows WSL properly
type: enhancement

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

From report at bugs.python.org  Sat Oct 23 14:48:44 2021
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 23 Oct 2021 18:48:44 +0000
Subject: [New-bugs-announce] [issue45590] distutils: Upload failed (400):
 Invalid value for blake2_256_digest
Message-ID: <1635014924.31.0.109934491156.issue45590@roundup.psfhosted.org>


New submission from Jakub Wilk <jwilk at jwilk.net>:

My "python3 setup.py sdist upload" failed with:

  Upload failed (400): Invalid value for blake2_256_digest. Error: Use a valid, hex-encoded, BLAKE2 message digest.

Apparently this is because distutils uses wrong digest size for Blake2:
https://github.com/pypa/distutils/issues/25

----------
components: Distutils
messages: 404904
nosy: christian.heimes, dstufft, eric.araujo, jwilk
priority: normal
severity: normal
status: open
title: distutils: Upload failed (400): Invalid value for blake2_256_digest
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Oct 23 17:28:44 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Sat, 23 Oct 2021 21:28:44 +0000
Subject: [New-bugs-announce] [issue45591] PathFinder does not find namespace
 packages children
Message-ID: <1635024524.91.0.931449499561.issue45591@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

```
$ tree namespace
namespace/
??? a.py

0 directories, 1 file
```

```
$ ./python
Python 3.9.7 (default, Oct 10 2021, 15:13:22)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib.machinery import PathFinder
>>> PathFinder.find_
PathFinder.find_distributions(  PathFinder.find_module(         PathFinder.find_spec(
>>> PathFinder.find_spec('namespace')
ModuleSpec(name='namespace', loader=None, submodule_search_locations=_NamespacePath(['/home/anubis/git/cpython/namespace']))
>>> PathFinder.find_spec('namespace.a')
```

Currently, it is unable to find namespace.a, but it should:

```
Python 3.11.0a1+ (heads/main:9e05da6224, Oct 23 2021, 20:36:14) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib.machinery import PathFinder
>>> spec = PathFinder.find_spec('namespace')
>>> spec.loader.load_module('namespace.a')
<frozen importlib._bootstrap>:283: DeprecationWarning: the load_module() method is deprecated and slated for removal in Python 3.12; use exec_module() instead
<module 'namespace.a' (<_frozen_importlib_external.NamespaceLoader object at 0x7f81b944f480>)>
```

I can make a PR, but just wanted to make sure the current behavior is not intended.

----------
messages: 404912
nosy: FFY00, brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: PathFinder does not find namespace packages children

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

From report at bugs.python.org  Sat Oct 23 17:36:36 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Sat, 23 Oct 2021 21:36:36 +0000
Subject: [New-bugs-announce] [issue45592] NamespaceLoader does not implement
 create_module or exec_module
Message-ID: <1635024996.39.0.539683336304.issue45592@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

NamespaceLoader currently does not implement create_module or exec_module, which is problematic since load_module is deprecated.

The create_module docstring is the same as _LoaderBasics:

```
def create_module(self, spec):
    """Use default semantics for module creation."""
```

Is it intended to be empty, or is NamespaceLoader unfinished?

If this is intended, how should we create the module instead? If there is other part of the code dealing this, via a fallback in case the loader does not implement this method, wouldn't it make sense to put that in in the loader itself for standalone use?

----------
messages: 404913
nosy: FFY00, brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: NamespaceLoader does not implement create_module or exec_module

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

From report at bugs.python.org  Sat Oct 23 19:08:32 2021
From: report at bugs.python.org (=?utf-8?q?Maciej_Urba=C5=84ski?=)
Date: Sat, 23 Oct 2021 23:08:32 +0000
Subject: [New-bugs-announce] [issue45593] SpooledTemporaryFile.truncate
 returns None
Message-ID: <1635030512.97.0.747524706746.issue45593@roundup.psfhosted.org>


New submission from Maciej Urba?ski <rooter at kyberian.net>:

Related:
https://bugs.python.org/issue40287
https://bugs.python.org/msg319145

----------
components: Library (Lib)
messages: 404914
nosy: rooter
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile.truncate returns None
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sun Oct 24 04:30:10 2021
From: report at bugs.python.org (Nathan Collins)
Date: Sun, 24 Oct 2021 08:30:10 +0000
Subject: [New-bugs-announce] [issue45594] Feature Request: add EHOSTUNREACH
 subclass to ConnectionError
Message-ID: <1635064210.44.0.451558275384.issue45594@roundup.psfhosted.org>


New submission from Nathan Collins <nathan.collins at gmail.com>:

WHAT

It would be nice if there was a special-case subclass of the standard library OSError/ConnectionError class for C EHOSTUNREACH (a.k.a. "no route to host") errors. Currently there are special-case subclasses of ConnectionError for several other types of connection errors, namely BrokenPipeError, ConnectionAbortedError, ConnectionRefusedError and ConnectionResetError. I'm asking that a new, similar subclass called HostUnreachableError be added, corresponding to C errno EHOSTUNREACH.

HOW

I believe this is as simple as adding four lines to CPython's exceptions.c, e.g. following ECONNABORTED's special treatment via the ConnectionAbortedError subclass there.

WHY

These special case OSError/ConnectionError exceptions are useful for several reasons. First, they give human friendly names to an otherwise less helpful OSError exceptions. Second, they make it easier to write portable code, because different OSes use different C errno numbers for the corresponding C error. For example, EHOSTUNREACH is errno 113 on Linux [1] and 110 on Windows [2].

[1] https://github.com/torvalds/linux/blob/9c0c4d24ac000e52d55348961d3a3ba42065e0cf/include/uapi/asm-generic/errno.h#L96
[2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-160

----------
components: Library (Lib)
messages: 404917
nosy: ntc2
priority: normal
severity: normal
status: open
title: Feature Request: add EHOSTUNREACH subclass to ConnectionError
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Oct 24 05:01:25 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Oct 2021 09:01:25 +0000
Subject: [New-bugs-announce] [issue45595] [Build] Make extensions depend on
 header files
Message-ID: <1635066085.24.0.0932129661238.issue45595@roundup.psfhosted.org>


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

Any change to a Python header file triggers a rebuild of Python core objects. The extension modules are not automatically rebuild in several cases. This is slightly annoying for core development because it forces me to do ``make clean`` too often.

* setup.py adds dependencies on Includes/*.h but not on header files in "internal" and "cpython" subdirectory
* Modules/Setup and makesetup do not add a dependency on PYTHON_HEADERS
* Modules/Setup is also missing dependencies on module-specific headers, e.g. _sre.o should depend on sre.h.

----------
assignee: christian.heimes
components: Build
messages: 404921
nosy: brett.cannon, christian.heimes
priority: normal
severity: normal
status: open
title: [Build] Make extensions depend on header files
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Oct 24 05:38:17 2021
From: report at bugs.python.org (Julien Palard)
Date: Sun, 24 Oct 2021 09:38:17 +0000
Subject: [New-bugs-announce] [issue45596] Python opens the ./<string> file
 on exception while using -c
Message-ID: <1635068297.43.0.0595906544239.issue45596@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

When running `python -c 'raise ValueError'` Python tries to open the '<string>' file, so:

    $ echo Coucou > '<string>'
    $ python -c 'raise ValueError'
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
        Coucou
    ValueError

----------
messages: 404922
nosy: mdk
priority: normal
severity: normal
status: open
title: Python opens the ./<string> file on exception while using -c

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

From report at bugs.python.org  Sun Oct 24 05:38:45 2021
From: report at bugs.python.org (Basil Peace)
Date: Sun, 24 Oct 2021 09:38:45 +0000
Subject: [New-bugs-announce] [issue45597] os.path.realpath returns invalid
 path for junction pointing to letter-less volume
Message-ID: <1635068325.62.0.0976139991665.issue45597@roundup.psfhosted.org>


New submission from Basil Peace <grv87 at yandex.ru>:

If a path contains a junction pointing to a dir on a letter-less drive then `os.path.realpath` returns `Volume{<uuid>}\dir`, without `\\?\` prefix. 

This path, of course, doesn't work correctly. Actually, it looks relative.

Original issue: https://github.com/pypa/pip/issues/10597

----------
components: Windows
messages: 404923
nosy: grv87, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.realpath returns invalid path for junction pointing to letter-less volume
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 24 08:05:01 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Oct 2021 12:05:01 +0000
Subject: [New-bugs-announce] [issue45598] setup.py grep_headers_for() is
 broken by design
Message-ID: <1635077101.64.0.462136707743.issue45598@roundup.psfhosted.org>


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

The setup.py helper function grep_headers_for() is used by ctypes build step to search header files for functions. The function kinda works on most platforms, but only by accident. On my system it opens all header files that match /usr/include/*.h and returns true if any (!) header file contains the string (!) "ffi_prep_cif_var". The check would also match "ffi_prep_cif_var" in a comment of an unrelated header file.

We cannot limit the search to "ffi.h" only, because that would break multiarch builds with a header file like this:

    #if defined(__i386__)
    #include "ffi-i386.h"
    #elif defined(__powerpc64__)
    #include "ffi-ppc64.h"
    ...

Solutions:

1) Use "AC_EGREP_HEADER" autoconf macro. It runs a header file through the C preprocessor
2) Use AC_LINK_IFELSE autoconf macro. This macro compiles and links code to detect if a library exports a function.
3) Re-implement any of the macros in pure Python (ugh!)
4) Just assume that libffi supports ffi_prep_cif_var, ffi_prep_closure_loc, and ffi_closure_alloc on our target platforms. According to [1] the functions have been around for over a decade.

I favor (4).

Ned, what about USING_APPLE_OS_LIBFFI? Is it still relevant?

[1] https://github.com/libffi/libffi/blame/48bdb02867edb7e9f3785ccb4bdff1087fb44246/include/ffi.h.in#L309

----------
components: Build, ctypes
messages: 404926
nosy: amaury.forgeotdarc, belopolsky, christian.heimes, meador.inge, ned.deily
priority: normal
severity: normal
status: open
title: setup.py grep_headers_for() is broken by design
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Oct 24 09:50:42 2021
From: report at bugs.python.org (Raphael)
Date: Sun, 24 Oct 2021 13:50:42 +0000
Subject: [New-bugs-announce] [issue45599] Please official support %G,
 %V and %u directives in time library
Message-ID: <1635083442.63.0.338428674269.issue45599@roundup.psfhosted.org>


New submission from Raphael <rafal1.1990 at o2.pl>:

In the time library documentation (https://docs.python.org/3/library/time.html) the directives %G, %V and %u for strftime() are missing, although they work (at least for me in Linux Mint):

$ python3
Python 3.8.10 (default, Sep 28 2021, 16:10:42) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import strftime
>>> strftime("%G-W%V-%u")
'2021-W42-7'

This seems to be officially supported by the datetime library since https://bugs.python.org/issue12006 or at least there is a section for the ISO 8601 week directives in the datetime documentation:
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes

I would like to see the same for the time library.

----------
components: Library (Lib)
messages: 404933
nosy: Raphael
priority: normal
severity: normal
status: open
title: Please official support %G, %V and %u directives in time library
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/issue45599>
_______________________________________

From report at bugs.python.org  Sun Oct 24 11:11:07 2021
From: report at bugs.python.org (Andrei Kulakov)
Date: Sun, 24 Oct 2021 15:11:07 +0000
Subject: [New-bugs-announce] [issue45600] First sentence in docs for
 os.environ
Message-ID: <1635088267.89.0.720866018266.issue45600@roundup.psfhosted.org>


New submission from Andrei Kulakov <andrei.avk at gmail.com>:

In os.eviron docs:

https://docs.python.org/3.11/library/os.html#os.environ

A mapping object representing the string environment.

Should that be "... the process environment." ?

----------
assignee: docs at python
components: Documentation
messages: 404934
nosy: andrei.avk, docs at python
priority: low
severity: normal
status: open
title: First sentence in docs for os.environ
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Oct 24 17:03:43 2021
From: report at bugs.python.org (Richard Hinerfeld)
Date: Sun, 24 Oct 2021 21:03:43 +0000
Subject: [New-bugs-announce] [issue45601] test_tk and test_ttk_guionly fail
 with resource not availiable
Message-ID: <1635109423.03.0.279475515853.issue45601@roundup.psfhosted.org>


New submission from Richard Hinerfeld <rhinerfeldhou at gmail.com>:

Please note that test_tk and test_ttk_guionly fail when running testall
when compiling 3.8.9 python from source code.
Compiling on Linux Debian 64-bit bullseye 11.1.0 on a 2008 Mac Book.

----------
components: Build
files: TestTK.txt
messages: 404942
nosy: rhinerfeld1
priority: normal
severity: normal
status: open
title: test_tk and test_ttk_guionly fail with resource not availiable
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file50393/TestTK.txt

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

From report at bugs.python.org  Sun Oct 24 22:25:53 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Mon, 25 Oct 2021 02:25:53 +0000
Subject: [New-bugs-announce] [issue45602] The grammar misses links that are
 present everywhere else
Message-ID: <1635128753.08.0.122680667814.issue45602@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

The grammar, in https://docs.python.org/3/reference/grammar.html , lacks some utilities that the remaining of the documentation have.
While it remains usable, it is hard to navigate. As an example https://www.python.org/dev/peps/pep-0634/ 's "star_named_exrpsession" and "block" links to the general grammar page, and indeed can't link to the specific rules as there are no anchor on them.
This would also allow a related improvement: being able to click on a rule R in the right side of a declaration and go to the definition of R. Given the recursive nature of grammar, that would transform a sequence of search into a sequence of click (and even allow to use the browser's "back" to go back to the previous definition, or to open the new definition in a new tab)

As far as I can tell, the first action would be to add a new kind of token on Doc/tools/extensions/peg_highlight.py , so that we distinguish the left and the right part of the rule. The left part (the name of the declared rule) would be easy to recognize as it always start on the beginning of the line and end with :.
The second action would be that, for each declaration D, the html would contain an anchor "#D". And each time D would appear on the right hand side of a rule, it would be in a link to #D

I suspect that adding those links and anchor could be done by overriding the default formatter or highlighter, but I don't understand pygment well enough to know what should be done here

----------
assignee: docs at python
components: Documentation
messages: 404946
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: The grammar misses links that are present everywhere else
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/issue45602>
_______________________________________

From report at bugs.python.org  Sun Oct 24 23:59:29 2021
From: report at bugs.python.org (Dean)
Date: Mon, 25 Oct 2021 03:59:29 +0000
Subject: [New-bugs-announce] [issue45603] [Windows]
Message-ID: <1635134369.55.0.048722857986.issue45603@roundup.psfhosted.org>


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

Running on Windows 10 Home PC, I'm running into an issue with Windows user account privileges and updating Python packages.

Upgrading a package (e.g. pip) with a lower-level user on Windows can result in a broken pip package (message of "no 'pip' package can be found").

It can be fixed by running (as admin):
python -m ensurepip

Then running an upgrade command as Admin.

Please consider enforcing Admin privileges for this action (upgrading packages).

----------
components: Library (Lib)
messages: 404949
nosy: hl2guide
priority: normal
severity: normal
status: open
title: [Windows]
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Oct 25 10:34:49 2021
From: report at bugs.python.org (Alex Wells)
Date: Mon, 25 Oct 2021 14:34:49 +0000
Subject: [New-bugs-announce] [issue45604] multiprocessing.log_to_stderr
 missing documentation for parameter
Message-ID: <1635172489.58.0.649582586734.issue45604@roundup.psfhosted.org>


New submission from Alex Wells <alex.wells at diamond.ac.uk>:

The documentation for multiprocessing.log_to_stderr() specifies that the method takes no parameters. However, intellisense in VSCode and debugging the method both show that there is a single parameter, "level", whose default value is None. 
Documentation here:
https://docs.python.org/3.7/library/multiprocessing.html#multiprocessing.log_to_stderr

The parameter appears to be a shorthand to allow you to both get the logger and specify the required log level in one step, rather than two. The code that handles the "level" parameter appears to do what I'd expect it to do.

I think the documentation simply needs a few words written about the parameter.

Thanks.

----------
assignee: docs at python
components: Documentation
messages: 404965
nosy: AlexWells, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.log_to_stderr missing documentation for parameter
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct 25 11:22:39 2021
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Mon, 25 Oct 2021 15:22:39 +0000
Subject: [New-bugs-announce] [issue45605] Return False from __contains__
 method if object not hashable for set and dict
Message-ID: <1635175359.85.0.710145859229.issue45605@roundup.psfhosted.org>


New submission from ?????? ???????? <heckad at yandex.ru>:

Now if do something like `[] in set()` python raise an exception, but if an object isn't hashable then we know for sure that it isn't in the set. Propose return False for these cases.

P.S. I would like to make a patch

----------
components: Library (Lib)
messages: 404971
nosy: heckad
priority: normal
severity: normal
status: open
title: Return False from __contains__ method if object not hashable for set and dict
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 25 15:20:55 2021
From: report at bugs.python.org (Rasmus Bondesson)
Date: Mon, 25 Oct 2021 19:20:55 +0000
Subject: [New-bugs-announce] [issue45606] pathlib.Path.glob() does not list
 dangling symlink when pattern is the exact filenane
Message-ID: <1635189655.12.0.290768542952.issue45606@roundup.psfhosted.org>


New submission from Rasmus Bondesson <raekmannen at gmail.com>:

Create a symlink that points to file that doesn't exist:

    ln -s /nonexisting_file my_symlink

Then try to glob for that symlink from Python using pathlib:

    python3
    >>> import pathlib
    >>> list(pathlib.Path(".").glob("my_symlink"))
    []
    >>> list(pathlib.Path(".").glob("my_symlink*"))
    [PosixPath('my_symlink')]

I'm a bit surprised that these two globs do not return the same results. Personally I would expect both to find the symlink.

Is this behaviour a bug or is it intentional?

----------
components: Library (Lib)
messages: 404996
nosy: raek
priority: normal
severity: normal
status: open
title: pathlib.Path.glob() does not list dangling symlink when pattern is the exact filenane
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 25 16:38:01 2021
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 25 Oct 2021 20:38:01 +0000
Subject: [New-bugs-announce] [issue45607] Make it possible to enrich an
 exception's error message
Message-ID: <1635194281.32.0.0583100270803.issue45607@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

The requirement comes from Hypothesis, see
https://github.com/python/cpython/pull/28569#discussion_r730338369

It is necessary there to add a note to an exception describing which test case it comes from. The note should be printed by __str__ of this exception. 


class Explanation(Exception):
    __module__ = "builtins"
    def __str__(self) -> str:
        return f"\n{self.args[0]}"

try:
    why = "Failed!"
    raise AssertionError(why)
except Exception as e:
    msg = "    You can reproduce this error by ...\n    ..."
    raise Explanation(msg) from e

    # Ideally something more like:
    e.__note__ = msg
    raise

----------
components: Interpreter Core
messages: 404999
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Make it possible to enrich an exception's error message
type: enhancement

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

From report at bugs.python.org  Mon Oct 25 17:40:00 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 25 Oct 2021 21:40:00 +0000
Subject: [New-bugs-announce] [issue45608] [sqlite3] some DB-API attributes
 are undocumented
Message-ID: <1635198000.59.0.313242486667.issue45608@roundup.psfhosted.org>


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

Some DB-API 2.0 attributes are undocumented:

- apilevel
- threadsafety
- paramstyle

These attributes should be documented.


See also:
- bpo-8196
- https://discuss.python.org/t/is-sqlite3-threadsafety-the-same-thing-as-sqlite3-threadsafe-from-the-c-library/11463

----------
assignee: docs at python
components: Documentation
messages: 405004
nosy: docs at python, erlendaasland, lemburg
priority: normal
severity: normal
status: open
title: [sqlite3] some DB-API attributes are undocumented
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Oct 25 20:42:26 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 26 Oct 2021 00:42:26 +0000
Subject: [New-bugs-announce] [issue45609] Specialize STORE_SUBSCR
Message-ID: <1635208946.04.0.990921573614.issue45609@roundup.psfhosted.org>


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

See the issue here for lots of data from before specializing: https://github.com/faster-cpython/ideas/issues/105

See https://gist.github.com/sweeneyde/91855e50feb9992b604ddda2d4f1511e for specialization data, pyperformance benchmarks, and microbenchmarks.

Right now the PR draft specializes list[int], dict[str], and bytearray[int], although I don't if the bytearray opcode should be kept. I considered specializing dict[object], but I figured the overhead of PyDict_SetItem isn't that much less than PyObject_SetItem.

----------
components: Interpreter Core
messages: 405015
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Specialize STORE_SUBSCR
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Mon Oct 25 22:29:21 2021
From: report at bugs.python.org (IYism)
Date: Tue, 26 Oct 2021 02:29:21 +0000
Subject: [New-bugs-announce] [issue45610] Cookies with longer paths are
 listed before cookies with shorter paths.
Message-ID: <1635215361.47.0.617081190698.issue45610@roundup.psfhosted.org>


New submission from IYism <admin at iyism.com>:

E.g:
Set-Cookie: a=1; Domain=test.com;      Path=/
Set-Cookie: a=2; Domain=demo.test.com; Path=/

Browser send Cookie: a=2; a=1


According to the agreed specification, a=2 should be read first, not a=1

But the wrong behavior of python is that the cookie reads a=1 by default

----------
components: Library (Lib)
messages: 405020
nosy: FFY00, IYism
priority: normal
pull_requests: 27486
severity: normal
status: open
title: Cookies with longer paths are listed before cookies with shorter paths.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 26 03:40:20 2021
From: report at bugs.python.org (Ian Currie)
Date: Tue, 26 Oct 2021 07:40:20 +0000
Subject: [New-bugs-announce] [issue45611] pprint - low width overrides depth
 folding
Message-ID: <1635234020.63.0.301729210201.issue45611@roundup.psfhosted.org>


New submission from Ian Currie <iansedano at gmail.com>:

Reproducible example:

>>> from pprint import pprint
>>> data = [["aaaaaaaaaaaaaaaaaa"],[2],[3],[4],[5]]
>>> pprint(data)
[["aaaaaaaaaaaaaaaaaa"], [2], [3], [4], [5]]

>>> pprint(data, depth=1)
[[...], [...], [...], [...], [...]]

>>> pprint(data, depth=1, width=7)
[[...],
 [...],
 [...],
 [...],
 [...]]

>>> pprint(data, depth=1, width=6)
[['aaaaaaaaaaaaaaaaaa'],
 [2],
 [3],
 [4],
 [5]]

The depth "folds" everything deeper than 1 level. Then if you lower the width of the output enough, what was once on one line, will now be split by newlines.

The bug is, if you lower the width below seven characters. Which is the length of `[[...],`  It seems to override the `depth` parameter and print the everything with no folding. This is true of deeply nested structures too.

Expected behavior: for the folding `...` to remain.

Why put the width so low?

I came across this because of the behavior of `compact`:

By default, if a data structure can fit on one line, it will be displayed on one line. `compact` only affects sequences that are longer than the given width.

**There is no way to force compact as False for short items**, so as to make sure all items, even short ones, appear on their own line.

[1,2,3] - will always appear on its own line, there is no way to make it appear like:

[1,
 2,
 3]

The only way is by setting a very low width.

----------
components: Library (Lib)
messages: 405027
nosy: iansedano
priority: normal
severity: normal
status: open
title: pprint - low width overrides depth folding
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 26 04:12:44 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 26 Oct 2021 08:12:44 +0000
Subject: [New-bugs-announce] [issue45612] [doc] add sqlite3 module docstring
Message-ID: <1635235964.69.0.602737413779.issue45612@roundup.psfhosted.org>


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

Currently, the sqlite3 module docstring is the old pysqlite copyright comment in the start of Lib/sqlite3/__init__.py. This is not very helpful to the general user. Suggesting to add a more helpful docstring, a la the 're' or 'array' modules (those two were randomly picked among stdlib modules with helpful docstrings).

----------
assignee: docs at python
components: Documentation
messages: 405030
nosy: docs at python, erlendaasland
priority: normal
severity: normal
status: open
title: [doc] add sqlite3 module docstring
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Oct 26 08:04:26 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 26 Oct 2021 12:04:26 +0000
Subject: [New-bugs-announce] [issue45613] [sqlite3] set threadsafety
 attribute based on default SQLite threaded mode
Message-ID: <1635249866.52.0.876924087674.issue45613@roundup.psfhosted.org>


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

Currently, the sqlite3 DB-API 2.0 attribute 'threadsafety' is hard-coded to 1, meaning "threads may share the module, but not connections". This is not always true, since it depends on the default SQLite threaded mode, selected at compile-time with the SQLITE_THREADSAFE define.

SQLite's default compile-time threaded mode is SQLITE_THREADSAFE=1, also known as "serialized threaded mode", meaning SQLite can be safely used by multiple threads with no restriction. This mode equals DB-API 2.0 threadsafety level 3: threads may share the module, connections and cursors.

On macOS 11.6, the system supplied Python 3 and SQLite 3 uses SQLITE_THREADSAFE=2 (also known as "multi-thread mode"), meaning SQLite can be safely used by multiple threads provided that no single database connection is used simultaneously in two or more threads. This mode equals DB-API 2.0 threadsafety level 1: threads may share the module, but not connections.

With SQLITE_THREADSAFE=0 (also known as "single-thread mode"), meaning all mutexes are disabled and SQLite is unsafe to use in more than a single thread at once. This mode equals DB-API 2.0 threadsafety level 0: threads may not share the module.


Suggesting to set the 'treadsafety' dynamically at sqlite3 module load time, either via Lib/sqlite3/dbapi2.py, or in C during module init (slightly faster).


See also:

- https://www.python.org/dev/peps/pep-0249/
- https://sqlite.org/threadsafe.html
- https://discuss.python.org/t/is-sqlite3-threadsafety-the-same-thing-as-sqlite3-threadsafe-from-the-c-library/11463/11

----------
assignee: erlendaasland
components: Extension Modules
messages: 405035
nosy: erlendaasland, lemburg
priority: normal
severity: normal
status: open
title: [sqlite3] set threadsafety attribute based on default SQLite threaded mode
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 26 08:05:47 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 26 Oct 2021 12:05:47 +0000
Subject: [New-bugs-announce] [issue45614] traceback of exception with
 non-unicode __module__
Message-ID: <1635249947.08.0.737111193049.issue45614@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

This test currently fails for both C and python tracebacks:

    def test_exception_modulename_not_unicode(self):
        class X(Exception):
            def __str__(self):
                return "I am X"

        X.__module__ = 42

        err = self.get_report(X())
        exp = f'<unknown>.{X.__qualname__}: I am X'
        self.assertEqual(exp, err)

----------
components: Interpreter Core, Library (Lib)
messages: 405037
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: traceback of exception with non-unicode __module__
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 26 11:17:10 2021
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 26 Oct 2021 15:17:10 +0000
Subject: [New-bugs-announce] [issue45615] Missing test for type of error
 when printing traceback for non-exception
Message-ID: <1635261430.95.0.190322958386.issue45615@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

In C code, there is a check in print_exception that the value passed in is of type exception, and it raises TypeError otherwise. This check is not covered by tests, and indeed it is hard to reach it with tests because the _testcapi module has this check as well, which blocks it before the interpreter's check is reached.


In traceback.py, there is no such check so this happens: 
>>> traceback.print_exception(12)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/iritkatriel/src/cpython-654/Lib/traceback.py", line 121, in print_exception
    value, tb = _parse_value_tb(exc, value, tb)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/iritkatriel/src/cpython-654/Lib/traceback.py", line 102, in _parse_value_tb
    raise TypeError(f"Expected exception, got {exc}")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Expected exception, got 12

----------
components: Interpreter Core, Library (Lib)
messages: 405048
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Missing test for type of error when printing traceback for non-exception
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Oct 26 13:51:14 2021
From: report at bugs.python.org (Gabe R. )
Date: Tue, 26 Oct 2021 17:51:14 +0000
Subject: [New-bugs-announce] [issue45616] Python Launcher Matches 3.10
 instead of 3.1
Message-ID: <1635270674.96.0.337719561337.issue45616@roundup.psfhosted.org>


New submission from Gabe R.  <gabrielcroper at gmail.com>:

I have both Python 3.1-64 and 3.10-64 installed on the same Windows machine. If I attempt to launch Python 3.1 using the command `py -3.1-64`, the launcher incorrectly starts Python 3.10.

----------
components: Windows
messages: 405054
nosy: Marsfan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python Launcher Matches 3.10 instead of 3.1
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Oct 26 15:20:29 2021
From: report at bugs.python.org (Kelly Brazil)
Date: Tue, 26 Oct 2021 19:20:29 +0000
Subject: [New-bugs-announce] [issue45617] sys.stdin does not iterate
 correctly on '\r' line separator
Message-ID: <1635276029.13.0.174464623283.issue45617@roundup.psfhosted.org>


New submission from Kelly Brazil <kellyjonbrazil at gmail.com>:

When iterating on sys.stdin lines, '\r\n' and '\n' are handled correctly, but '\r' is not handled, though it is documented that it should be supported.

Example code:
import sys

for line in sys.stdin:
    print(repr(line))

Results in Python 3.8.9:
$ echo -e 'line1\nline2\nline3' | python3 linetest.py 
'line1\n'
'line2\n'
'line3\n'

$ echo -e 'line1\r\nline2\r\nline3' | python3 linetest.py 
'line1\r\n'
'line2\r\n'
'line3\n'

$ echo -e 'line1\rline2\rline3' | python3 linetest.py 
'line1\rline2\rline3\n'

----------
messages: 405057
nosy: kbrazil
priority: normal
severity: normal
status: open
title: sys.stdin does not iterate correctly on '\r' line separator
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 26 18:34:59 2021
From: report at bugs.python.org (Maciej Olko)
Date: Tue, 26 Oct 2021 22:34:59 +0000
Subject: [New-bugs-announce] [issue45618] Documentation builds fail with
 Sphinx 3.2.1
Message-ID: <1635287699.66.0.0951441516371.issue45618@roundup.psfhosted.org>


New submission from Maciej Olko <maciej.olko at gmail.com>:

Since the release of Docutils 0.18 today building Python documentation fails.

In CPython repository we have Sphinx pinned to 3.2.1, which has too loose requirement for Docutils version in install_requires ? docutils>=0.12.

Example of failing build: https://github.com/python/python-docs-pl/runs/4009459257.

My suggestion is to pin down docutils in docs requirements.

----------
assignee: docs at python
components: Documentation
messages: 405060
nosy: Maciej Olko, docs at python
priority: normal
severity: normal
status: open
title: Documentation builds fail with Sphinx 3.2.1
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/issue45618>
_______________________________________

From report at bugs.python.org  Tue Oct 26 22:27:59 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Wed, 27 Oct 2021 02:27:59 +0000
Subject: [New-bugs-announce] [issue45619] Mentioning structural pattern
 matching in the list of binding
Message-ID: <1635301679.85.0.944511615119.issue45619@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

https://docs.python.org/3/reference/executionmodel.html list all of the way a variable may be bound. However, it seems that it was not updated. Indeed, structural pattern matching in 3.10 also allows to bind a variable and is not mentionned.

As a related issue, the sentence is far too long and really would need to be broken down. At the very least, the special case "and targets that are identifiers if" is not clear, it is not indicated whether this case extends to the end of the sentence or is just local

----------
assignee: docs at python
components: Documentation
messages: 405066
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: Mentioning structural pattern matching in the list of binding
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Oct 27 01:39:20 2021
From: report at bugs.python.org (Sonia)
Date: Wed, 27 Oct 2021 05:39:20 +0000
Subject: [New-bugs-announce] [issue45620] A misleading url in 'Floating
 Point Arithmetic' page
Message-ID: <1635313160.15.0.740336077946.issue45620@roundup.psfhosted.org>


New submission from Sonia <hsiaohanwu at gmail.com>:

The url of [The Perils of Floating Point](http://www.lahey.com/float.htm) seems a bit weird in the page https://docs.python.org/3/tutorial/floatingpoint.html. It redirects me to a webpage that sells dugs. Not sure if the resource was meant to find this: http://www.stat.cmu.edu/~brian/711/week03/perils-of-floating-point.pdf

----------
messages: 405070
nosy: hanhantw
priority: normal
severity: normal
status: open
title: A misleading url in 'Floating Point Arithmetic' page
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 27 03:37:27 2021
From: report at bugs.python.org (Tim Golden)
Date: Wed, 27 Oct 2021 07:37:27 +0000
Subject: [New-bugs-announce] [issue45621] Small fixes to mmap
Message-ID: <1635320247.38.0.208723521187.issue45621@roundup.psfhosted.org>


New submission from Tim Golden <mail at timgolden.me.uk>:

Following issue40915 a few small items still need to be addressed, mostly cosmetic / naming:

* A comment should have been removed but wasn't
* A comment should have been added but wasn't
* The use of the string "TEST" should be avoided in tests particularly where there is a shared namespace and therefore the chance of a collision

----------
assignee: tim.golden
messages: 405073
nosy: tim.golden
priority: low
severity: normal
status: open
title: Small fixes to mmap
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 04:38:26 2021
From: report at bugs.python.org (=?utf-8?q?Florin_Sp=C4=83tar?=)
Date: Wed, 27 Oct 2021 08:38:26 +0000
Subject: [New-bugs-announce] [issue45622] BlockingIOError: [Errno 11]
 Resource temporarily unavailable when performing SSL handshake on Solaris
Message-ID: <1635323906.56.0.962809052121.issue45622@roundup.psfhosted.org>


New submission from Florin Sp?tar <florin.spatar at gmail.com>:

Trying to connect to an uWSGI (or any other) server, from Solaris, will fail with the following error:

-bash-3.00# /opt/opsware/agent/bin/python3 client.py 
/tmp/client.py:9: DeprecationWarning: ssl.PROTOCOL_TLS is deprecated
  context = ssl.SSLContext(ssl.PROTOCOL_TLS)
Exception in thread Thread-1 (make_connection):
Traceback (most recent call last):
  File "/opt/opsware/agent/lib/python3.10/threading.py", line 1009, in _bootstrap_inner
    self.run()
  File "/opt/opsware/agent/lib/python3.10/threading.py", line 946, in run
    self._target(*self._args, **self._kwargs)
  File "/tmp/client.py", line 13, in make_connection
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
  File "/opt/opsware/agent/lib/python3.10/ssl.py", line 512, in wrap_socket
    return self.sslsocket_class._create(
  File "/opt/opsware/agent/lib/python3.10/ssl.py", line 1070, in _create
    self.do_handshake()
  File "/opt/opsware/agent/lib/python3.10/ssl.py", line 1341, in do_handshake
    self._sslobj.do_handshake()
BlockingIOError: [Errno 11] Resource temporarily unavailable

I used the following client code (based on https://docs.python.org/3.10/library/ssl.html#socket-creation):

import socket
import ssl
import threading

hostname = '192.168.135.9'
port = 1004

def make_connection():
	context = ssl.SSLContext(ssl.PROTOCOL_TLS)

	with socket.create_connection((hostname, port)) as sock:
		sock.settimeout(300) # use non-blocking I/O
		with context.wrap_socket(sock, server_hostname=hostname) as ssock:
			print(ssock.version())


t=threading.Thread(target=make_connection)
t.start()
t.join()

This works fine on multiple Linux distros, AIX, and HP-UX. It even seems to work on Solaris Sparc. There seems to be an issue only on Solaris (5.10/5.11) x86.
Furthermore, in order to reproduce the issue, the SSL handshake needs to be performed from a thread and use non-blocking I/O. If I use blocking I/O or don't use thread, the issue doesn't reproduce anymore.

The issues first started to appear in python 3.8.5 when I switched from openssl 1.0.2u to 1.1.1k. The issue is still reproducible with python 3.10 and openssl 3.0.0

----------
assignee: christian.heimes
components: SSL
files: client.py
messages: 405076
nosy: christian.heimes, florinspatar
priority: normal
severity: normal
status: open
title: BlockingIOError: [Errno 11] Resource temporarily unavailable when performing SSL handshake on Solaris
type: behavior
versions: Python 3.10, Python 3.8
Added file: https://bugs.python.org/file50394/client.py

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

From report at bugs.python.org  Wed Oct 27 06:30:32 2021
From: report at bugs.python.org (egorpugin)
Date: Wed, 27 Oct 2021 10:30:32 +0000
Subject: [New-bugs-announce] [issue45623] static build is broken
Message-ID: <1635330632.5.0.689915843766.issue45623@roundup.psfhosted.org>


New submission from egorpugin <egor.pugin at gmail.com>:

Static build is not working any more since 3.10.

'winver' member is only defined with dll build.

See master - 'winver' call which is not available for windows+static build.
https://github.com/python/cpython/blob/main/Lib/site.py#L292

See 3.9 file - no 'winver' call.
https://github.com/python/cpython/blob/1016ef37904c7ddc16fb18d3369b2a78cf428fa4/Lib/site.py#L266

Error:
```
1>EXEC : Fatal Python error : init_import_site: Failed to import the site module
1>Python runtime state: initialized
1>Traceback (most recent call last):
1>  File "D:\dev\swst\pkg\8b\0a\10a9\src\sdir\Lib\site.py", line 657, in <module>
1>    main()
1>  File "D:\dev\swst\pkg\8b\0a\10a9\src\sdir\Lib\site.py", line 643, in main
1>    known_paths = addusersitepackages(known_paths)
1>  File "D:\dev\swst\pkg\8b\0a\10a9\src\sdir\Lib\site.py", line 380, in addusersitepackages
1>    user_site = getusersitepackages()
1>  File "D:\dev\swst\pkg\8b\0a\10a9\src\sdir\Lib\site.py", line 367, in getusersitepackages
1>    USER_SITE = _get_path(userbase)
1>  File "D:\dev\swst\pkg\8b\0a\10a9\src\sdir\Lib\site.py", line 332, in _get_path
1>    ver_nodot = sys.winver.replace('.', '')
1>AttributeError: module 'sys' has no attribute 'winver'
```

----------
messages: 405082
nosy: egorpugin
priority: normal
severity: normal
status: open
title: static build is broken
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Oct 27 07:03:09 2021
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Wed, 27 Oct 2021 11:03:09 +0000
Subject: [New-bugs-announce] [issue45624] test_graphlib.py depends on
 iteration order of sets
Message-ID: <1635332589.87.0.491015468348.issue45624@roundup.psfhosted.org>


New submission from Carl Friedrich Bolz-Tereick <cfbolz at gmx.de>:

test_graphlib fails on PyPy because it depends on the iteration order of sets. Will open a PR soon.

----------
messages: 405084
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: test_graphlib.py depends on iteration order of sets

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

From report at bugs.python.org  Wed Oct 27 07:38:05 2021
From: report at bugs.python.org (Fred)
Date: Wed, 27 Oct 2021 11:38:05 +0000
Subject: [New-bugs-announce] [issue45625] Add support for top-level await
Message-ID: <1635334685.92.0.999778106074.issue45625@roundup.psfhosted.org>


New submission from Fred <eldmannen at gmail.com>:

I want top-level await without any boilerplate code or setup.
Just write a "await" statement on line 1 without any indention.

    #!/usr/bin/env python3
    import asyncio
    await asyncio.sleep(1)


I don't want to have to call asyncio.run(main()), and I don't  want to have to put the await inside an async function.

----------
components: Interpreter Core
messages: 405088
nosy: Fred
priority: normal
severity: normal
status: open
title: Add support for top-level await
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 08:57:54 2021
From: report at bugs.python.org (John Howroyd)
Date: Wed, 27 Oct 2021 12:57:54 +0000
Subject: [New-bugs-announce] [issue45626] Email part with content type
 message is multipart.
Message-ID: <1635339474.91.0.560715467663.issue45626@roundup.psfhosted.org>


New submission from John Howroyd <jdhowroyd at googlemail.com>:

>From the library documentation, it is an intended feature that an email part with content_maintype == "message" is treated as multipart.  This does not seem to be compliant to MIME specification nor expected semantics.  The attached email (from the dnc wikileaks collection) is a good example where this logic breaks down.

Code:
import pathlib
pth = "16155.eml" # path to example
import email
import email.parser
parser = email.parser.BytesParser()
fl = pth.open("rb")
eml = parser.parse(fl)
pts = [p for p in eml.walk()]
len(pts) # returns 52

Here pts[0] is the root part of content_type 'multipart/report'.
Then pts[1] has content_type 'multipart/alternative' containing the 'text/plain' pts[2] and the 'text/html' pts[3] (which most email clients would consider the message (of this email).  All good so far.

The problem is that pts[4] of content_type 'message/delivery-status' which has pts[4].is_multipart() [True] and contains 46 sub parts as returned by pts[4].get_payload(): these are pts[5], ... , pts[50]. Finally, pts[51] has content_type 'text/rfc822-headers' which is fine.

Each of the subparts of pts[4] (pts[5:51]) have "" returned by pts[n].get_payload() as their content is treated as headers. Where as pts[4].as_bytes includes the header (and separating blank line) for that part; namely, b'Content-Type: message/delivery-status\n\n'.

Looking at the raw file and in particular the MIME boundary makers it would seem to me that pts[4] should not be considered multipart and that there is no indication from a content-type of 'message/delivery-status' should or even could be considered an (rfc822) email.

Moreover, as the main developer of a system to forensically analyse large (million +) corpora of emails this behaviour of treating parts even of the specific content-type 'message/rfc822' is undisarable; typically, these occur as part of bounce messages and have their content-disposition set to 'attachment'.  As a developer what would seem more natural in the case that this behaviour is wanted would be to test parts for the content-type 'message/rfc822' and pass the .get_payload(decode=True) to the bytes parser parser.parse() method.

I appreciate the need to support backwards compatibility, so presumably this would require an addition to email.policy to govern which parts should be treated as multipart.  I would be more than happy to submit a patch for this but fear it would be rejected out of hand (as the original intent is clearly to parse out contained emails).

----------
components: Library (Lib)
files: 16155.eml
messages: 405091
nosy: jdhowroyd
priority: normal
severity: normal
status: open
title: Email part with content type message is multipart.
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50396/16155.eml

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

From report at bugs.python.org  Wed Oct 27 09:16:46 2021
From: report at bugs.python.org (Alexandru Ardelean)
Date: Wed, 27 Oct 2021 13:16:46 +0000
Subject: [New-bugs-announce] [issue45627] OpenSSL 1.1.1 still implements
 some disable-flags for Blake2, Scrypt
Message-ID: <1635340606.96.0.794905902875.issue45627@roundup.psfhosted.org>


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

This follows update https://bugs.python.org/issue43669

Which is present in Python 3.10

Some OpenSSL 1.1.1 can be built without Blake2 support or Scrypt.

SHA3 and SHAKE do not seem to have any enable/disable flags.

This results in compiler errors where EVP_blake2b512, EVP_blake2s256, EVP_PBE_scrypt and PKCS5_v2_scrypt_keyivgen can be un-defined.

This is unfortunate behavior on the part of OpenSSL 1.1.1.

So, for BLAKE2 and SCRYPT, we should still check that the OPENSSL_NO_SCRYPT and OPENSSL_NO_BLAKE2 defines are not-define.

----------
assignee: christian.heimes
components: Build, Extension Modules, SSL
messages: 405093
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Oct 27 11:23:13 2021
From: report at bugs.python.org (Ivo Grondman)
Date: Wed, 27 Oct 2021 15:23:13 +0000
Subject: [New-bugs-announce] [issue45628] TimedRotatingFileHandler
 backupCount not working
Message-ID: <1635348193.15.0.970239577461.issue45628@roundup.psfhosted.org>


New submission from Ivo Grondman <python at grondman.net>:

Using the TimedRotatingFileHandler with a non-zero backupCount, I get different behaviour between versions 3.9 and 3.10.

Attached is a small example. Running it with 3.9 gives me two backups at most even if I run the script for a long time. Running it with 3.10 does not delete old backup files at all and just keeps writing new ones.

----------
components: Library (Lib), macOS
files: logrotate.py
messages: 405104
nosy: ivogrondman, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler backupCount not working
versions: Python 3.10
Added file: https://bugs.python.org/file50397/logrotate.py

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

From report at bugs.python.org  Wed Oct 27 11:42:12 2021
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Oct 2021 15:42:12 +0000
Subject: [New-bugs-announce] [issue45629] Tools/freeze needs tests in the
 test suite.
Message-ID: <1635349332.56.0.690000934648.issue45629@roundup.psfhosted.org>


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

I found that Tools/freeze doesn't get tested.  It has a "test" directory but it's more of a rudimentary sanity check that must be run manually.  Since the tool isn't tested through our test suite, there's a high likelihood it can get broken without anyone realizing it.  The risk has increased with recent changes to frozen modules.  So such tests would be valuable.

The tool requires that Python be installed.  In the context of our test suite, this means configuring with a temp dir prefix and then re-building.  We must do it in a separate directory to avoid affecting other tests.

I'm planning on adding a test that does the following:

1. create a temp dir (TMPDIR)
2. copy the repo to TMPDIR/cpython
3. run configure there with --prefix=TMPDIR/python-installation
4. run make -j
5. run make install -j
6. write a simple script to TMPDIR/app.py
7. run the "freeze" tool on it, with minimal options
8. run the frozen app and verify it worked

Note that there needs to be enough disk space for all that (which not all buildbots have).  Also, the test will be relatively slow due to having to re-build.

There aren't any other tests that re-build Python or the like, so I'm a little hesitant to set precedent.  Perhaps that's why there weren't any tests already.  However, I don't see any significant reasons to not add the test (as long as it doesn't lead to spurious failures).

----------
assignee: eric.snow
components: Demos and Tools
messages: 405105
nosy: eric.snow, lemburg
priority: normal
severity: normal
stage: test needed
status: open
title: Tools/freeze needs tests in the test suite.
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 11:47:45 2021
From: report at bugs.python.org (penguin_wwy)
Date: Wed, 27 Oct 2021 15:47:45 +0000
Subject: [New-bugs-announce] [issue45630] Dump CodeObject API for debugging
Message-ID: <1635349665.14.0.891838928636.issue45630@roundup.psfhosted.org>


New submission from penguin_wwy <940375606 at qq.com>:

What the title says.

----------
components: Interpreter Core
messages: 405106
nosy: penguin_wwy
priority: normal
severity: normal
status: open
title: Dump CodeObject API for debugging
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 12:36:51 2021
From: report at bugs.python.org (paul j3)
Date: Wed, 27 Oct 2021 16:36:51 +0000
Subject: [New-bugs-announce] [issue45631] missing unittests for overlapping
 dest when using subparsers
Message-ID: <1635352611.83.0.329101262928.issue45631@roundup.psfhosted.org>


New submission from paul j3 <ajipanca at gmail.com>:

https://bugs.python.org/issue45235
argparse does not preserve namespace with subparser defaults

was passed and put into the latest release with rather obvious buggy behavior.  

This means that the unittest file does not adequately test for overlapping 'dest' in the main and subparsers.  It probably also does not test many (any?) cases of user provided namespace.

Issue9351 added a test, but it only tested defaults set with 

parser.set_defaults(foo=1)
xparser.set_defaults(foo=2)

not the more common practice of setting defaults in add_argument.

45235 adds one test, but again only for 

xparser.set_defaults(foo=1)

It doesn't test for user inputs, as with

['X','--foo=3']

----------
messages: 405110
nosy: ALSchwalm, paul.j3, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: missing unittests for overlapping dest when using subparsers

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

From report at bugs.python.org  Wed Oct 27 13:24:21 2021
From: report at bugs.python.org (doraeric)
Date: Wed, 27 Oct 2021 17:24:21 +0000
Subject: [New-bugs-announce] [issue45632] Strange readline save history
 behaviour in site.py
Message-ID: <1635355461.27.0.071759404055.issue45632@roundup.psfhosted.org>


New submission from doraeric <benson.doraemon at gmail.com>:

I noticed that in site.py, it saves history to a hard-coded location if the current history length is 0. The history is considered as not loaded if the length is 0, but it may be actually loaded from a empty file. In this case, the history is save to hard-coded ~/.python_history, and maybe another user-defined location in PYTHONSTARTUP file.

I think a better solution is to export some config or functions from site.py, so users can explicitly disable the atexit callback from site.py.

---
[site.py] https://github.com/python/cpython/blob/b9cdd0fb9c463c2503a4d854bb6529a9db58fe1b/Lib/site.py#L470-L491

----------
components: Library (Lib)
messages: 405114
nosy: doraeric
priority: normal
severity: normal
status: open
title: Strange readline save history behaviour in site.py
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Oct 27 14:28:11 2021
From: report at bugs.python.org (Julien Palard)
Date: Wed, 27 Oct 2021 18:28:11 +0000
Subject: [New-bugs-announce] [issue45633] Py_GT listed twice in
 Doc/extending/newtypes.rst
Message-ID: <1635359291.67.0.00111122399866.issue45633@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In Doc/extending/newtypes one can read:

> This function is called with two Python objects and the operator as arguments, where the operator is one of Py_EQ, Py_NE, Py_LE, Py_GT, Py_LT or Py_GT.

It bet one of them should be Py_GE.

(I let this one as an easy first contrib.)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 405119
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: Py_GT listed twice in Doc/extending/newtypes.rst

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

From report at bugs.python.org  Wed Oct 27 17:02:56 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Wed, 27 Oct 2021 21:02:56 +0000
Subject: [New-bugs-announce] [issue45634] [sqlite3] don't combine error
 checks when adding integer constants
Message-ID: <1635368576.72.0.458292729425.issue45634@roundup.psfhosted.org>


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

In Modules/_sqlite/module.c, add_integer_constants() accumulates the return values of repeated PyModule_AddIntMacro() calls. We should change this to instead bailing immediately on error.

----------
components: Extension Modules
messages: 405124
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] don't combine error checks when adding integer constants
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Oct 27 17:27:06 2021
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 27 Oct 2021 21:27:06 +0000
Subject: [New-bugs-announce] [issue45635] Tidy up error handling in
 traceback.c / python run.c
Message-ID: <1635370026.46.0.0220648873339.issue45635@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

They do things like 

    err = PyFile_WriteString("TypeError: print_exception(): Exception expected for value, ", f);
    err += PyFile_WriteString(Py_TYPE(value)->tp_name, f);
    err += PyFile_WriteString(" found\n", f);

which means that PyFile_XXX functions are called after error. They should return (abort printing the exception) instead.


It gets even more interesting with PyFile_WriteObject calls - this function asserts that the exception is not set, so the code calls PyErr_Clear() before calling PyFile_WriteObject(). It should avoid making the call altogether.

----------
assignee: iritkatriel
messages: 405126
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Tidy up error handling in traceback.c / python run.c

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

From report at bugs.python.org  Wed Oct 27 18:13:52 2021
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 27 Oct 2021 22:13:52 +0000
Subject: [New-bugs-announce] [issue45636] Merge BINARY_*/INPLACE_* into
 BINARY_OP/INPLACE_OP
Message-ID: <1635372832.22.0.99301821488.issue45636@roundup.psfhosted.org>


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

...as discussed in https://github.com/faster-cpython/ideas/issues/101.

This change merges all BINARY_*/INPLACE_* instructions, except for a few special cases:

- BINARY_ADD/INPLACE_ADD, which interact with sq_concat/sq_inplace_concat and already have their own specialization family.
- BINARY_MULTIPLY/INPLACE_MULTIPLY, which interact with sq_repeat/sq_inplace_repeat and already have their own specialization family.
- BINARY_POWER/INPLACE_POWER, which are technically ternary operators under-the-hood.
- BINARY_MODULO/INPLACE_MODULO, which contain a special fast path for string formatting (but likely can be rolled in later as a specialization).

It has no mean impact on pyperformance, shrinks the eval loop, and makes it much simpler to implement operator specializations.

----------
assignee: brandtbucher
components: Interpreter Core
messages: 405136
nosy: Mark.Shannon, brandtbucher, gvanrossum
priority: normal
severity: normal
status: open
title: Merge BINARY_*/INPLACE_* into BINARY_OP/INPLACE_OP
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 19:26:30 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Oct 2021 23:26:30 +0000
Subject: [New-bugs-announce] [issue45637] The fallback to find the current
 frame in the gdb helpers fails for inlined frames
Message-ID: <1635377190.26.0.872789937299.issue45637@roundup.psfhosted.org>


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

This code does not work in the presence of inlined Python calls:

https://github.com/python/cpython/blob/d02ffd1b5c0fd8dec6dd2f7e3f2b0cfae48b7899/Tools/gdb/libpython.py#L1804-L1813

----------
components: Interpreter Core
messages: 405140
nosy: Mark.Shannon, pablogsal
priority: normal
severity: normal
status: open
title: The fallback to find the current frame in the gdb helpers fails for inlined frames
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 20:05:44 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 28 Oct 2021 00:05:44 +0000
Subject: [New-bugs-announce] [issue45638] Does ccbench still require 2.6
 compatibility?
Message-ID: <1635379544.92.0.412444620127.issue45638@roundup.psfhosted.org>


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

At the top of Tools/ccbench/ccbench.py is this comment dating from 2010 (probably in the initial version):

# This file should be kept compatible with both Python 2.6 and Python >= 3.0.

Is there still a need for 2.6 compatibility in what is essentially a test script? There are probably only a few changes necessary to remove 2.x compatibility, but it seems odd to retain them when even the Python library documentation no longer has versionchanged/versionadded directives referencing Python 2.x.

----------
messages: 405141
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Does ccbench still require 2.6 compatibility?
versions: Python 3.11

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

From report at bugs.python.org  Wed Oct 27 22:33:34 2021
From: report at bugs.python.org (Adam Konrad)
Date: Thu, 28 Oct 2021 02:33:34 +0000
Subject: [New-bugs-announce] [issue45639] Support modern image formats in
 MIME types
Message-ID: <1635388414.48.0.724029722643.issue45639@roundup.psfhosted.org>


New submission from Adam Konrad <kixorz at gmail.com>:

Modern image types webp and avif are not recognized by the mimetypes module.

Problem: Many tools are written in Python and running on macOS. Good example is the AWS CLI. Running commands like "s3 sync" will save files with .webp and .avif extensions with incorrect "binary/octet-stream" Content-Type to S3. This creates additional problems with serving these resources over HTTP.

The webp and avif image types are supported by most browsers: https://caniuse.com/#feat=webp
https://caniuse.com/#feat=avif

While webp is fully supported and largely used, it is not officially registered with IANA.

Avif is currently less popular, it is fully registered with IANA.
https://www.iana.org/assignments/media-types/media-types.xhtml

Please consider the attached GitHub PR as a fix to these MIME Content-Type issues.

----------
components: Library (Lib)
messages: 405145
nosy: adamkonrad
priority: normal
severity: normal
status: open
title: Support modern image formats in MIME types
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/issue45639>
_______________________________________

From report at bugs.python.org  Wed Oct 27 23:04:26 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Thu, 28 Oct 2021 03:04:26 +0000
Subject: [New-bugs-announce] [issue45640] Production tokens are not clickable
Message-ID: <1635390266.57.0.202926795869.issue45640@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

In the current documentation, production tokens are not clickable. For example in https://docs.python.org/3/reference/expressions.html#yield-expressions , you highlight `yield_from` as a token but do not link to it.
I suppose that the goal, when using :token:`yeld_from`, was to ensure that the token links to its definition. However, Sphinx require to use :token:`~python-grammar:yeld_from` for the link to appear. 

I suggest adding ~python-grammar after each token:.

----------
assignee: docs at python
components: Documentation
messages: 405147
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: Production tokens are not clickable
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/issue45640>
_______________________________________

From report at bugs.python.org  Thu Oct 28 02:38:12 2021
From: report at bugs.python.org (Dev Kumar)
Date: Thu, 28 Oct 2021 06:38:12 +0000
Subject: [New-bugs-announce] [issue45641] Error In opening a file through
 Idle
Message-ID: <1635403092.77.0.425701800447.issue45641@roundup.psfhosted.org>


New submission from Dev Kumar <devesh.dk373 at gmail.com>:

there is an error that is occurring in opening a file or program & after that python is started hanging & not even quitting.
And also the file which is open by python is not even saving or executing.

----------
assignee: terry.reedy
components: IDLE, macOS
messages: 405149
nosy: devesh.dk373, ned.deily, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: Error In opening a file through Idle
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 28 05:26:35 2021
From: report at bugs.python.org (Craig Dowkes)
Date: Thu, 28 Oct 2021 09:26:35 +0000
Subject: [New-bugs-announce] [issue45642] Unable to save
Message-ID: <1635413195.38.0.0518815063217.issue45642@roundup.psfhosted.org>


New submission from Craig Dowkes <craig.dowkes at gmail.com>:

I recently updated to Mac OS Montery 12.0.1 and am now unable to open or save any idle files. Running on a 2021 M1 iMac. I get the save dialogue box but then also an error box as shown in the attached picture. Failed to connect to the open and save panel service.

----------
files: Screenshot 2021-10-28 at 10.24.11 am.jpg
messages: 405168
nosy: craig.dowkes
priority: normal
severity: normal
status: open
title: Unable to save
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file50406/Screenshot 2021-10-28 at 10.24.11 am.jpg

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

From report at bugs.python.org  Thu Oct 28 06:31:03 2021
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 28 Oct 2021 10:31:03 +0000
Subject: [New-bugs-announce] [issue45643] SIGSTKFLT is missing from the
 signals module on Linux
Message-ID: <1635417063.88.0.746261778756.issue45643@roundup.psfhosted.org>


New submission from Gareth Rees <gdr at garethrees.org>:

BACKGROUND

On Linux, "man 7 signal" includes SIGSTKFLT in its table of "various other signals":

    Signal     Value   Action  Comment
    ???????????????????????????????????????????????????????????????
    SIGSTKFLT  -,16,-   Term   Stack fault on coprocessor (unused)

Here "-,16,-" means that the signal is defined with the value 16 on x86 and ARM but not on Alpha, SPARC or MIPS. I believe that the intention was to use SIGSTKFLT for stack faults on the x87 math coprocessor, but this was either removed or never implemented, so that the signal is defined in /usr/include/signal.h but not used by the Linux kernel.


USE CASE

SIGSTKFLT is one of a handful of signals that are not used by the kernel, so that user-space programs are free to use it for their own purposes, for example for inter-thread or inter-process pre-emptive communication.

Accordingly, it would be nice if the name SIGSTKFLT were available in the Python signal module on the platforms where the signal is available, for use and reporting in these cases.

----------
components: Library (Lib)
messages: 405174
nosy: gdr at garethrees.org
priority: normal
severity: normal
status: open
title: SIGSTKFLT is missing from the signals module on Linux
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 08:59:07 2021
From: report at bugs.python.org (Chris Wesseling)
Date: Thu, 28 Oct 2021 12:59:07 +0000
Subject: [New-bugs-announce] [issue45644] Make json.tool soak up input
 before opening output for writing
Message-ID: <1635425947.02.0.769956758277.issue45644@roundup.psfhosted.org>


New submission from Chris Wesseling <chris.wesseling at xs4all.nl>:

json.tool is very cute and handy for making json readable.

But rewriting a file in place requires tools like sponge (on POSIX) or a tmpfile, because 

$ python -m json.tool foo.json foo.json

results in an empty foo.json.

I propose soaking up the infile before opening the outfile for writing, to prevent that. Much like sort -o does, but without the explicit flag.
The patch I have prepared changes no behaviours, other than preventing an empty file... (still I see this as an enhancement and not a bug fix)

----------
messages: 405182
nosy: CharString
priority: normal
severity: normal
status: open
title: Make json.tool soak up input before opening output for writing
type: enhancement

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

From report at bugs.python.org  Thu Oct 28 10:12:52 2021
From: report at bugs.python.org (PABLO LOBATO DE LA CRUZ)
Date: Thu, 28 Oct 2021 14:12:52 +0000
Subject: [New-bugs-announce] [issue45645] Deep recursion terminates script
 execution with no error (Windows, Python 3.9)
Message-ID: <1635430372.32.0.809866843445.issue45645@roundup.psfhosted.org>


New submission from PABLO LOBATO DE LA CRUZ <pablolob at ucm.es>:

Deep recursion crashes on Windows (Python 3.9) when the depth limit is increased and no error is shown.
Seems to work fine on other systems that I have tried (Linux and MacOS).
Please find attached the script to reproduce the error.
Expected and other systems output:

Calculated N2
Try block finished correctly
This is the finally block

Output:

Calculated N2

----------
components: Windows
files: forstack.py
messages: 405185
nosy: pablolob, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Deep recursion terminates script execution with no error (Windows, Python 3.9)
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file50407/forstack.py

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

From report at bugs.python.org  Thu Oct 28 10:42:22 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Thu, 28 Oct 2021 14:42:22 +0000
Subject: [New-bugs-announce] [issue45646] The documentation wrongly uses
 or_expr for star expresion in displays
Message-ID: <1635432142.42.0.274045830946.issue45646@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

According to the current documentation, I believe there is an error in
list_display, set_display and dict_display.
According to list display, this is a valid expression
[* l1 ^ l2]
parsed as
list_display:
  "["
  starred_list:
    starred_item:
      "*"
      or_expr:
        xor_expr:
          xor_expr: "l1"
          "^"
          and_expr: "l2"
  "]"  

I add the full derivation from and_expr to l2 at the end of the report, it's not important for this topic. 

The same issue is present for set. For dictionary it is also present, but instead the error is in key_datum.

I have no idea what would be the proper correction.
Indeed [*l1+l2] is valid (in 3.9) at least. So it's not like the element after a star is restricted to be an atom.

At the very least, I believe it should be clearly indicated that, contrary to what the name indicates, "or_expr" do not mean that we accept any or, nor any expression. It just mean that 
*some_complex_expression
is interpreted as
* (some_complex_expression)
and that it is valid iff some_complex_expression is valid



            shift_expr:
              a_expr:
                m_expr:
                  power:
                    primary:
                      atom:
                        identifier:
                          "l2"

----------
assignee: docs at python
components: Documentation
messages: 405187
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: The documentation wrongly uses or_expr for star expresion in displays
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/issue45646>
_______________________________________

From report at bugs.python.org  Thu Oct 28 10:51:26 2021
From: report at bugs.python.org (Arthur Milchior)
Date: Thu, 28 Oct 2021 14:51:26 +0000
Subject: [New-bugs-announce] [issue45647] "expression" is erroneous in the
 doc
Message-ID: <1635432686.87.0.829733368222.issue45647@roundup.psfhosted.org>


New submission from Arthur Milchior <arthur at milchior.fr>:

https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression is wrong
This line state:
`expression             ::=  conditional_expression | lambda_expr`
and it is a problem because, by the way sphinx understand reference, this mean that any people who use the token `expression` will be linked to this particular line.
For example in https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-key_datum
`key_datum          ::=  expression ":" expression | "**" or_expr`
while clearly a key_datum is not expecting only a conditional expression or a lambda expression.

Admittedly, you can derive, from  expression:
* conditional_expression
* or_test
* and_test
* not_test
* comparison
* or_expr
* xor_expr
* and_expr
* shift_expr
* a_expr
* m_expr
* u_expr
* power
* primary
* atom

in this order, so in practice you can probably derive most of the expressions. However, I doubt that this is what the documentation meant here, and clearly not practical.

----------
assignee: docs at python
components: Documentation
messages: 405189
nosy: Arthur-Milchior, docs at python
priority: normal
severity: normal
status: open
title: "expression" is erroneous in the doc
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/issue45647>
_______________________________________

From report at bugs.python.org  Thu Oct 28 10:53:27 2021
From: report at bugs.python.org (Ken Jin)
Date: Thu, 28 Oct 2021 14:53:27 +0000
Subject: [New-bugs-announce] [issue45648] Better tp_version_tag overflow
 checks in specializer
Message-ID: <1635432807.78.0.734832288442.issue45648@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Unless I'm mistaken, the current code in Python/specialize.c doesn't check for valid tp_version_tag, so version tag could overflow and it wouldn't know any better.

Ideally, we should add more robust tests for when tp_version_tag overflows, but that's a project for another day.

----------
messages: 405190
nosy: Mark.Shannon, kj
priority: normal
severity: normal
status: open
title: Better tp_version_tag overflow checks in specializer
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 11:59:21 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Thu, 28 Oct 2021 15:59:21 +0000
Subject: [New-bugs-announce] [issue45649] Add tarinfo.Path
Message-ID: <1635436761.88.0.225530702286.issue45649@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

It would be helpful to have a pathlib-compatible object in tarfile, similarly to zipfile.Path.

----------
components: Library (Lib)
messages: 405194
nosy: FFY00, jaraco
priority: normal
severity: normal
status: open
title: Add tarinfo.Path
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 12:47:19 2021
From: report at bugs.python.org (Kier Davis)
Date: Thu, 28 Oct 2021 16:47:19 +0000
Subject: [New-bugs-announce] [issue45650] cgitb does not emit CGI headers
 when format='text'
Message-ID: <1635439639.23.0.69927337911.issue45650@roundup.psfhosted.org>


New submission from Kier Davis <me at kierdavis.com>:

## Context ##

* Python is executing a script on behalf of a web server (e.g. Apache httpd) following the CGI protocol.
* cgitb is enabled and configured to use the 'text' format.
* An unhandled exception occurs before any CGI response headers have been emitted.


## Expected behaviour ##

A valid response is returned from the CGI script to the web server and ultimately to the client.


## Observed behaviour ##

The response is rejected by the web server because it does not begin with a valid CGI header block.

    [cgi:error] [pid xxxxx] [client xxx.xxx.xxx.xxx:xxxxx] malformed header from script 'web.py': Bad header: <p>A problem occurred in a Pyt

Any traceback info included (if display=1) gets discarded and the web server returns its own Internal Server Error response instead.


## Comments ##

A valid response is observed if format='html'. This bug only concerns format='text'.
The behaviour is the same regardless of whether display=0 or display=1.

I imagine this is because cgitb.reset (which emits the headers) is only called when format='html'.
We could resolve this by always calling cgitb.reset regardless of the format, or by introducing separate text-format and HTML-format versions of cgitb.reset.
I'm happy to prepare a patch if you agree on the approach.

----------
components: Library (Lib)
files: repro_cgitb_not_emitting_headers_in_text_mode.py
messages: 405198
nosy: kierdavis
priority: normal
severity: normal
status: open
title: cgitb does not emit CGI headers when format='text'
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/file50409/repro_cgitb_not_emitting_headers_in_text_mode.py

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

From report at bugs.python.org  Thu Oct 28 13:09:35 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 17:09:35 +0000
Subject: [New-bugs-announce] [issue45651] -X frozen_modules not defaulting
 to "on" on Windows?
Message-ID: <1635440975.82.0.890486444721.issue45651@roundup.psfhosted.org>


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

(forked from https://bugs.python.org/issue45020#msg404344)

On Mon, Oct 18, 2021 at 7:14 PM Guido van Rossum <report at bugs.python.org> wrote:
> I built on Windows with default options (PCbuild\build.bat) and it looks like the frozen modules are used by default even though I am running in the source directory. (I put a printf() call in unmarshal_frozen_code().)

We need to verify if this is still the case.  First we need to make sure there's a test that checks the default (both when running out of the source tree and when not).  I suspect the case Guido observed hasn't been fixed yet.

----------
components: Interpreter Core
messages: 405201
nosy: FFY00, eric.snow
priority: normal
severity: normal
status: open
title: -X frozen_modules not defaulting to "on" on Windows?
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 13:45:27 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 17:45:27 +0000
Subject: [New-bugs-announce] [issue45652] co_filename does not match
 __file__ for frozen stdlib modules
Message-ID: <1635443127.89.0.781576963083.issue45652@roundup.psfhosted.org>


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

Frozen modules currently have co_filename set to "<frozen NAME>".  It would be good to have it match __file__ instead.  This will require require also fixing any code objects in the module's co_consts (and so on).  It may make sense to take care of the while unmarshaling, but could be done (less efficiently) after the fact.

----------
components: Interpreter Core
messages: 405209
nosy: FFY00, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: co_filename does not match __file__ for frozen stdlib modules
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 14:11:52 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 18:11:52 +0000
Subject: [New-bugs-announce] [issue45653] Freeze the encodings module.
Message-ID: <1635444712.46.0.923300343963.issue45653@roundup.psfhosted.org>


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

Currently we freeze all the modules imported during runtime initialization, except for the encodings module.  It has a lot of submodules and this results in a lot of extra noise in builds.  We hadn't frozen it yet because we were still ironing out changes related to frozen modules and the extra noise was a pain.  We also waited because we weren't sure if we should freeze all the submodules or just the most likely ones to be used during startup.  In the case of the latter, we were also blocked on having __path__ set on the package.

At this point there are no blockers.  So we should freeze the encodings modules with either all submodules or the most commonly used subset.

----------
components: Build
messages: 405211
nosy: FFY00, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Freeze the encodings module.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 14:13:50 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 18:13:50 +0000
Subject: [New-bugs-announce] [issue45654] Freeze the runpy module.
Message-ID: <1635444830.43.0.574749380857.issue45654@roundup.psfhosted.org>


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

Currently we are freezing the modules that are imported during startup.  However, if someone uses "python -m module" then the runtime imports the runpy module and uses it.  Given that this case is quite common, runpy and its dependencies should be frozen.

----------
components: Build
messages: 405212
nosy: FFY00, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Freeze the runpy module.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 14:20:51 2021
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 28 Oct 2021 18:20:51 +0000
Subject: [New-bugs-announce] [issue45655] List of PEPs at top of typing docs
 is too long to be readable
Message-ID: <1635445251.29.0.272820285555.issue45655@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

The list of relevant PEPs at the top of the typing docs has become too long to be readable or helpful. It would be good if this information could be presented in a more structured way.

----------
assignee: docs at python
components: Documentation
messages: 405215
nosy: AlexWaygood, docs at python, gvanrossum, kj
priority: normal
severity: normal
status: open
title: List of PEPs at top of typing docs is too long to be readable
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Oct 28 14:27:12 2021
From: report at bugs.python.org (Samwyse)
Date: Thu, 28 Oct 2021 18:27:12 +0000
Subject: [New-bugs-announce] [issue45656] argparse bug: prefix_chars
 argument to add_argument_group doesn't really work
Message-ID: <1635445632.13.0.297943907791.issue45656@roundup.psfhosted.org>


New submission from Samwyse <samwyse at gmail.com>:

Using the prefix_chars argument to parser.add_argument_group causes usage information to print correctly, but the resulting parser doesn't recognize the options.  The included program reproduces the issue; it produces the following output on my system.

--- python version
3.6.8 (default, Sep 26 2019, 11:57:09)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
--- test using prefix_chars='-/' with ArgumentParser
--- show help info
usage: test-1 [-h] [-foo FOO] [/bar BAR]

optional arguments:
  -h, --help  show this help message and exit
  -foo FOO
  /bar BAR

--- try parsing something
Namespace(bar='b', foo='f')
--- test using prefix_chars='-/' with an argument group
--- show help info
usage: test-2 [-h] [-foo FOO] [/bar BAR]

optional arguments:
  -h, --help  show this help message and exit

other arguments:
  -foo FOO
  /bar BAR

--- try parsing something
usage: test-2 [-h] [-foo FOO] [/bar BAR]
test-2: error: unrecognized arguments: /bar b

----------
components: Library (Lib)
files: argparser-bug.py
messages: 405217
nosy: samwyse
priority: normal
severity: normal
status: open
title: argparse bug: prefix_chars argument to add_argument_group doesn't really work
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file50410/argparser-bug.py

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

From report at bugs.python.org  Thu Oct 28 14:27:45 2021
From: report at bugs.python.org (Ronald Pandolfi)
Date: Thu, 28 Oct 2021 18:27:45 +0000
Subject: [New-bugs-announce] [issue45657] Enum behavior when values are
 functions
Message-ID: <1635445665.36.0.256719462717.issue45657@roundup.psfhosted.org>


New submission from Ronald Pandolfi <ronpandolfi at gmail.com>:

Enum members assigned values that are functions don't remember those members. For example:

def my_func():
    ...
class Test(enum.Enum):
    a=1
    b=my_func
    
Test.__members__
Out[7]: mappingproxy({'a': <Test.a: 1>})
Test.b
Out[8]: <function __main__.my_func()>

Even though b doesn't show in __members__ it is still an attribute of the Enum.

----------
messages: 405218
nosy: ronpandolfi
priority: normal
severity: normal
status: open
title: Enum behavior when values are functions
versions: Python 3.10

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

From report at bugs.python.org  Thu Oct 28 14:36:49 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 18:36:49 +0000
Subject: [New-bugs-announce] [issue45658] Implement
 FrozenImporter.get_source()
Message-ID: <1635446209.12.0.0681665636182.issue45658@roundup.psfhosted.org>


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

FrozenImporter (in Lib/importlib/_bootstrap.py) has a get_source() method but it always returns None.  Now that __file__ is set on frozen (stdlib) modules, we can implement FrozenImporter.get_source() appropriately.

----------
components: Library (Lib)
messages: 405219
nosy: FFY00, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement FrozenImporter.get_source()
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 14:52:00 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 18:52:00 +0000
Subject: [New-bugs-announce] [issue45659] Add FrozenImporter.get_filename().
Message-ID: <1635447120.3.0.343001717774.issue45659@roundup.psfhosted.org>


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

Now that __file__ is set on frozen (stdlib) modules, we can add an implementation for FrozenImporter.get_filename().  This would make FrozenImporter and implementation of ExecutionLoader. [1]

There is a caveat: in spec_from_loader() [2] we infer the presence of get_filename() to mean the loader is file-based, which FrozenImporter isn't. 
 In that case we call spec_from_file_location() [3], which should not be used for frozen modules.  Most importantly, spec.origin for frozen modules should remain "frozen", spec.cached should remain None, and spec.has_location should remain False.  That's because the module was imported frozen and not from a file (even though it originated in a file).


[1] https://docs.python.org/3/library/importlib.html#importlib.abc.ExecutionLoader
[2] in Lib/import/_bootstrap.py
[3] in Lib/import/_bootstrap_external.py

----------
components: Library (Lib)
messages: 405225
nosy: FFY00, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Add FrozenImporter.get_filename().
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 15:17:10 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 19:17:10 +0000
Subject: [New-bugs-announce] [issue45660] Freeze the argparse module.
Message-ID: <1635448630.65.0.970845991528.issue45660@roundup.psfhosted.org>


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

(See https://bugs.python.org/issue45020#msg402116.)

On Fri, Sep 17, 2021 at 7:56 PM Raymond Hettinger <report at bugs.python.org> wrote:
> It would be nice to freeze argparse.py and its dependencies.  For command-line tools, startup time is important.

This would include freezing the modules that argparse depends on, etc.

----------
components: Build
messages: 405231
nosy: FFY00, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Freeze the argparse module.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 15:39:40 2021
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Oct 2021 19:39:40 +0000
Subject: [New-bugs-announce] [issue45661] [meta] Freeze commonly used stdlib
 modules.
Message-ID: <1635449980.31.0.181297451997.issue45661@roundup.psfhosted.org>


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

We're already freezing modules needed for bootstrapping the runtime, as well as the modules imported during startup. [1][2]  We're also planning on freezing argparse. [3]  There may be other modules (or files) worth freezing (assuming we don't just freeze the entire stdlib, which would have some potential downsides).

This issue is meant to cover the broader idea.  The work to actually freeze modules should be handled in separate issues.


[1] https://bugs.python.org/issue45020
[2] https://bugs.python.org/issue45654
[3] https://bugs.python.org/issue45660

----------
components: Build
messages: 405239
nosy: FFY00, eric.snow
priority: normal
severity: normal
status: open
title: [meta] Freeze commonly used stdlib modules.
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Oct 28 15:46:03 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Oct 2021 19:46:03 +0000
Subject: [New-bugs-announce] [issue45662] Incorrect repr of InitVar of a
 type alias
Message-ID: <1635450363.22.0.969198768309.issue45662@roundup.psfhosted.org>


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

The repr of InitVar preserves type aliases from the typing module, but not builtin.

>>> import typing, dataclasses
>>> dataclasses.InitVar[typing.List[int]]
dataclasses.InitVar[typing.List[int]]
>>> dataclasses.InitVar[list[int]]
dataclasses.InitVar[list]

----------
components: Library (Lib)
messages: 405241
nosy: eric.smith, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Incorrect repr of InitVar of a type alias
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Oct 28 16:10:31 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Oct 2021 20:10:31 +0000
Subject: [New-bugs-announce] [issue45663] is_dataclass() does not work for
 dataclasses which are subclasses of types.GenericAlias
Message-ID: <1635451831.16.0.493312475993.issue45663@roundup.psfhosted.org>


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

>>> import dataclasses, types
>>> @dataclasses.dataclass
... class A(types.GenericAlias):
...     origin: type
...     args: type
... 
>>> dataclasses.is_dataclass(A)
True
>>> a = A(list, int)
>>> dataclasses.is_dataclass(type(a))
True
>>> dataclasses.is_dataclass(a)
False

----------
components: Library (Lib)
messages: 405256
nosy: eric.smith, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: is_dataclass() does not work for dataclasses which are subclasses of types.GenericAlias
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Oct 28 16:38:27 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Oct 2021 20:38:27 +0000
Subject: [New-bugs-announce] [issue45664] resolve_bases() and new_class() do
 not work with type alias of a built-in type
Message-ID: <1635453507.8.0.842225708276.issue45664@roundup.psfhosted.org>


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

resolve_bases() returns incorrect result:

>>> import types
>>> types.resolve_bases((list[int],))
(list[int],)

Expected (list,).

new_class() fails:

>>> types.new_class('L', (list[int],), {})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/types.py", line 77, in new_class
    return meta(name, resolved_bases, ns, **kwds)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: GenericAlias expected 2 arguments, got 3

Both work well with typing.List[int].

----------
components: Library (Lib)
messages: 405265
nosy: gvanrossum, kj, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: resolve_bases() and new_class() do not work with type alias of a built-in type
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct 29 04:27:43 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Oct 2021 08:27:43 +0000
Subject: [New-bugs-announce] [issue45665] Problems caused by
 isinstance(list[int]) returning True
Message-ID: <1635496063.98.0.5366836652.issue45665@roundup.psfhosted.org>


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

This is a meta-issue for problems caused by isinstance(list[int]) returning True.

See also discussion in issue45438.

----------
components: Library (Lib)
messages: 405290
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Problems caused by isinstance(list[int]) returning True
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Oct 29 05:46:48 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 29 Oct 2021 09:46:48 +0000
Subject: [New-bugs-announce] [issue45666] Warning: "'swprintf' : format
 string '%s' requires an argument of type 'unsigned short *',
 but variadic argument 1 has type 'const char *'"
Message-ID: <1635500808.24.0.905348748425.issue45666@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

Right now GitHub emmits this warning:

```
GitHub Actions / Windows (x64)

Programs/_testembed.c#L1735

'swprintf' : format string '%s' requires an argument of type 'unsigned short *', but variadic argument 1 has type 'const char *' [D:\a\cpython\cpython\PCbuild\_testembed.vcxproj]

```

Example: https://github.com/python/cpython/pull/29272/files#file-programs-_testembed-c-L1735

Source: https://github.com/python/cpython/blob/7bddd96982072d04bd6314da1ee7f40b7f875f00/Programs/_testembed.c#L1736

I will send a PR with the fix.

----------
components: Library (Lib)
messages: 405296
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Warning: "'swprintf' : format string '%s' requires an argument of type 'unsigned short *', but variadic argument 1 has type 'const char *'"
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 29 06:00:06 2021
From: report at bugs.python.org (Julien Palard)
Date: Fri, 29 Oct 2021 10:00:06 +0000
Subject: [New-bugs-announce] [issue45667] Better error message on failing to
 create a venv due to failing ensurepip
Message-ID: <1635501606.61.0.0312062282004.issue45667@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

Currently if ensurepip fails for a reason or another, for example if a wrong module gets imported:

$ touch http.py
$ python3.10 -m venv .venv
Error: Command '['/tmp/.venv/bin/python3.10', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

the error is not helpfull. Maybe venv should just dump the stderr from ensurepip so we can learn a bit more about it (it's ??understandable?? in ensurepip traceback that it's in relation with http.py, in the given example.)

----------
messages: 405297
nosy: mdk
priority: normal
severity: normal
status: open
title: Better error message on failing to create a venv due to failing ensurepip

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

From report at bugs.python.org  Fri Oct 29 10:37:29 2021
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 29 Oct 2021 14:37:29 +0000
Subject: [New-bugs-announce] [issue45668] Some PGO tests are failing when
 building with --enable-optimizations --disable-test-modules
Message-ID: <1635518249.11.0.537805942695.issue45668@roundup.psfhosted.org>


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

Some PGO tests are failing when Python is build with options ./configure --disable-test-modules --enable-optimizations . Test failures are caused by missing _testcapi module.

./python -m test --pgo --timeout=1200 || true
test test_array failed
test test_bytes failed
test test_cmath failed
test test_codecs failed
0:00:23 load avg: 1.98 [13/44] test_datetime
Failed to call load_tests:
...
ModuleNotFoundError: No module named '_testcapi'
test test_embed failed
test test_float failed
test test_itertools failed
test test_ordered_dict failed
test test_pickle failed
test test_struct failed
test test_unicode failed
test test_xml_etree_c failed
test_xml_etree_c failed (3 errors)

----------
components: Build, Tests
messages: 405308
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Some PGO tests are failing when building with --enable-optimizations --disable-test-modules
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 29 12:11:03 2021
From: report at bugs.python.org (Paolo Melchiorre)
Date: Fri, 29 Oct 2021 16:11:03 +0000
Subject: [New-bugs-announce] [issue45669] An 'ascii_alphanumerics' variable
 is missing in the 'strings' lib
Message-ID: <1635523863.84.0.534508316323.issue45669@roundup.psfhosted.org>


New submission from Paolo Melchiorre <paolo at melchiorre.org>:

It is very common to construct a variable containing alphanumeric values as a basis for generating random strings, especially in the web environment as a slug to be used in URLs:

>>> import string
>>> ascii_alphanumerics = string.ascii_letters + string.digits
>>> ascii_alphanumerics
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'


I suggest inserting a variable for just this purpose directly into Python's "string" module:

>>> import string
>>> string.ascii_alphanumerics
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'

----------
components: Library (Lib)
messages: 405315
nosy: pauloxnet
priority: normal
severity: normal
status: open
title: An 'ascii_alphanumerics' variable is missing in the 'strings' lib
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 29 12:36:50 2021
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 29 Oct 2021 16:36:50 +0000
Subject: [New-bugs-announce] [issue45670] New .mapping attribute is broken
 for some existing uses of dict views
Message-ID: <1635525410.44.0.846161043783.issue45670@roundup.psfhosted.org>


New submission from Joshua Bronson <jabronson at gmail.com>:

As of bpo-40890 (released in Python 3.10), dict views now provide a public .mapping attribute, intended to allow users to recover a mappingproxy pointing to the original mapping.

However, this new attribute can actually point to the wrong mapping for some existing uses of dict views. And since the .mapping attribute is read-only, these existing uses have no way to set it to the correct value.

My bidict library (see https://github.com/jab/bidict) provides an example of this.

A bidict implements a bidirectional mapping by building on top of two dicts (i.e. regular old one-directional mappings) internally -- one for the forward direction, and one for the inverse. When you call e.g. keys() or values() on a bidict, you get back a dict_keys view from one of the backing dicts, because this is a much more optimized implementation of these views than collections.abc.KeysView would be:

>>> import bidict
>>> b = bidict.bidict(one=1, two=2)
>>> b
bidict({'one': 1, 'two': 2})
>>> b.keys()
dict_keys(['one', 'two'])
>>> b.values()
dict_keys([1, 2])


However, now that these built-in dict_keys objects provide a .mapping attribute in Python 3.10, it points to one of the internal, backing dicts in this case, which is an implementation detail, rather than to the bidict instance:

>>> b.keys().mapping  # wrong
mappingproxy({'one': 1, 'two': 2})
>>> b.values().mapping  # wrong
mappingproxy({1: 'one', 2: 'two'})


Instead of the above, you should get:

>>> b.keys().mapping  # corrected:
mappingproxy(bidict({'one': 1, 'two': 2}))
>>> b.values().mapping  # corrected:
mappingproxy(bidict({'one': 1, 'two': 2}))


Since the .mapping attribute is read-only, there's no way for bidict to both keep exposing the optimized dict_keys implementations, which up till now have been perfectly correct, while now exposing a correct .mapping attribute for users of Python 3.10+.

(Other bidict types demonstrate this problem more by exposing even more obviously-unintended implementation details via this new .mapping attribute:

>>> f = bidict.FrozenOrderedBidict(b)
>>> f
FrozenOrderedBidict([('one', 1), ('two', 2)])
>>> f.keys().mapping  # ouch
mappingproxy({'one': _Node(prv=..., self=..., nxt=...), 'two': _Node(prv=..., self=..., nxt=...)})

Those internal _Node objects were never meant to be exposed to consumers, they're an implementation detail.)


It looks like cases like this were not considered when discussing bpo-40890, and if they had been, I wonder if the implementation would have been accepted as-is.

Here are some potential directions for how to improve things for the future:

1. Expose a way for dict view users like bidict to continue to use optimized dict view implementations while opting out of the new .mapping attribute

2. Make the .mapping attribute no longer read-only, so libraries like bidict can set it correctly before exposing it to users

3. Merely update the documentation in https://docs.python.org/3/library/stdtypes.html#:~:text=dictview.mapping,in%20version%203.10. to mention that, because the .mapping attribute is read-only, it may not point to the original, intended mapping, but rather some internal mapping that the user was not intended to be exposed to.


Looking forward to hearing your thoughts, and thanks for your consideration.

----------
components: Interpreter Core
messages: 405317
nosy: jab, rhettinger
priority: normal
severity: normal
status: open
title: New .mapping attribute is broken for some existing uses of dict views
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Oct 29 12:48:16 2021
From: report at bugs.python.org (lilydjwg)
Date: Fri, 29 Oct 2021 16:48:16 +0000
Subject: [New-bugs-announce] [issue45671] str(CancelledError()) is empty
Message-ID: <1635526096.46.0.894887931952.issue45671@roundup.psfhosted.org>


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

When I try to print an asyncio.CancelledError object, I do not see it and I thought something went wrong.

CancelledError inherits from BaseException and all BaseException subclasses (e.g. SystemExit, KeyboardInterrupted) seem to return empty strings for str(e). While I never tried to print SystemExit or KeyboardInterrupted, I did try to print an CancelledError. It doesn't have a lot information but all other exceptions I tried to print return something so I expect CancelledError to be the same.

I know repr(e). I was just lazy and I expect Python to not be confusing even I'm lazy.

----------
components: asyncio
messages: 405318
nosy: asvetlov, lilydjwg, yselivanov
priority: normal
severity: normal
status: open
title: str(CancelledError()) is empty
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 29 12:52:34 2021
From: report at bugs.python.org (Nikita Sobolev)
Date: Fri, 29 Oct 2021 16:52:34 +0000
Subject: [New-bugs-announce] [issue45672] Mutation tests results of typing.py
Message-ID: <1635526354.62.0.519981897591.issue45672@roundup.psfhosted.org>


New submission from Nikita Sobolev <mail at sobolevn.me>:

I've decided to test `typing.py` with `cosmic-ray` mutation testing framework. It identified 3 potential problems.

Config:

```
[cosmic-ray]
module-path = "Lib/typing.py"
timeout = 15.0
excluded-modules = []
test-command = "./python.exe -m test -v test_typing --failfast"

[cosmic-ray.distributor]
name = "local"
```

Repro steps:
0. pip install cosmic-ray
1. Copy config above as `typing.toml`
2. cosmic-ray init typing.toml typing.sqlite
3. cosmic-ray exec tutorial.toml tutorial.sqlite 

Survived mutants:

1. ```
--- mutation diff ---
--- aLib/typing.py
+++ bLib/typing.py
@@ -1103,7 +1103,7 @@
             if Protocol in bases:
                 return ()
             i = bases.index(self)
-            for b in bases[i+1:]:
+            for b in bases[i*1:]:
                 if isinstance(b, _BaseGenericAlias) and b is not self:
                     return ()
         return (self.__origin__,)
```

2. ```
--- mutation diff ---
--- aLib/typing.py
+++ bLib/typing.py
@@ -1103,7 +1103,7 @@
             if Protocol in bases:
                 return ()
             i = bases.index(self)
-            for b in bases[i+1:]:
+            for b in bases[i//1:]:
                 if isinstance(b, _BaseGenericAlias) and b is not self:
                     return ()
         return (self.__origin__,)
```

3. ```
--- mutation diff ---
--- aLib/typing.py
+++ bLib/typing.py
@@ -1103,7 +1103,7 @@
             if Protocol in bases:
                 return ()
             i = bases.index(self)
-            for b in bases[i+1:]:
+            for b in bases[i**1:]:
                 if isinstance(b, _BaseGenericAlias) and b is not self:
                     return ()
         return (self.__origin__,)
```

I've attached the full report to this issue if it is interesting to anyone: https://gist.github.com/sobolevn/79f1729dcf0b8c4b2a9bcee67027673a

----------
components: Tests
messages: 405319
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Mutation tests results of typing.py
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 29 13:06:05 2021
From: report at bugs.python.org (Paolo Benvenuto)
Date: Fri, 29 Oct 2021 17:06:05 +0000
Subject: [New-bugs-announce] [issue45673] argparse error with option with
 optional value
Message-ID: <1635527165.05.0.842141756958.issue45673@roundup.psfhosted.org>


New submission from Paolo Benvenuto <paolobenve at gmail.com>:

I'm using argparse with this code:

parser = argparse.ArgumentParser(
    description='Scan a media tree in order to generate cache files suitable for showing a beautiful web gallery',
  )
  parser.add_argument(
    "config_file_or_album_path",
    help="the config file, if it's the only positional argument, or the album path, if two positional arguments are supplied"
  )
  parser.add_argument(
    "cache_path",
    nargs="?",
    default="",
    help="the cache path, if two positional arguments are supplied; otherwise, nothing"
  )
  parser.add_argument(
    "-s",
    "--periodic-save",
    nargs="?",
    type=int,
    const=5,
    default=0,
    dest="periodic_save",
    metavar="MINUTES",
    help="runs the scanner in a more robust way, saving json files every X minutes, where X is the value given, or 5 if no value is given; 0 means non autosaving"
  )
  parser.add_argument(
    "-j",
    "--recreate-json-files",
    action='store_true',
    dest="recreate_json_files",
    help="completely recreate the json files cache"
  )
  parser.add_argument(
    "-r",
    "--recreate-reduced-photos",
    action='store_true',
    dest="recreate_reduced_photos",
    help="completely recreate reduced photo cache files"
  )
  parser.add_argument(
    "-t",
    "--recreate-thumbnails",
    action='store_true',
    dest="recreate_thumbnails",
    help="completely recreate thumbnail cache files"
  )
  parser.add_argument(
    "-v",
    "--recreate-transcoded-videos",
    action='store_true',
    dest="recreate_transcoded_videos",
    help="completely recreate transcoded video cache files"
  )
  parser.add_argument(
    "-a",
    "--recreate-all",
    action='store_true',
    dest="recreate_all",
    help="completely recreate the cache: json files, reduced photos, thumbnails and transcoded videos; same as -jrtv"
  )
  parser.add_argument("--version", action="version", version='%(prog)s v5.3.10')
  args = parser.parse_args()

Running the app without parameter gives me:

$ myapp
usage: scanner [-h] [-s [MINUTES]] [-j] [-r] [-t] [-v] [-a] [--version] config_file_or_album_path [cache_path]
myapp: error: the following arguments are required: config_file_or_album_path

(the last line doesn't matter here, a required parameter is missing).

The -s option is optional and has an optional value, but:

$ myapp -s myfile
usage: scanner [-h] [-s [MINUTES]] [-j] [-r] [-t] [-v] [-a] [--version] config_file_or_album_path [cache_path]
scanner: error: argument -s/--periodic-save: invalid int value: '/my/file'

I'm expecting that, since there is a mandatory positional argument, myfile is interpreted as such, and only after that, -s is recognized as the optional argument without value.

----------
components: Library (Lib)
messages: 405322
nosy: paolobenve
priority: normal
severity: normal
status: open
title: argparse error with option with optional value
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 29 14:35:49 2021
From: report at bugs.python.org (Tristan)
Date: Fri, 29 Oct 2021 18:35:49 +0000
Subject: [New-bugs-announce] [issue45674] From Python 3.7,
 sre_parse.parse() do not create SubPattern instances that can be
 used to back reproduce original expression if containing non-capturing
 groups
Message-ID: <1635532549.63.0.469467756484.issue45674@roundup.psfhosted.org>


New submission from Tristan <trislatr at gmail.com>:

>From Python 3.7, sre_parse.parse() do not create SubPattern instances that can be used to back reproduce original expression if containing non-capturing groups. 

In Python 3.6: 

>>> import sre_parse
>>> sre_parse.parse("(?:foo (?:bar) | (?:baz))").dump()
SUBPATTERN None 0 0
  BRANCH
    LITERAL 102
    LITERAL 111
    LITERAL 111
    LITERAL 32
    SUBPATTERN None 0 0
      LITERAL 98
      LITERAL 97
      LITERAL 114
    LITERAL 32
  OR
    LITERAL 32
    SUBPATTERN None 0 0
      LITERAL 98
      LITERAL 97
      LITERAL 122


In Python 3.7 and beyond: 

>>> import sre_parse
>>> sre_parse.parse("(?:foo (?:bar) | (?:baz))").dump()
BRANCH
  LITERAL 102
  LITERAL 111
  LITERAL 111
  LITERAL 32
  LITERAL 98
  LITERAL 97
  LITERAL 114
  LITERAL 32
OR
  LITERAL 32
  LITERAL 98
  LITERAL 97
  LITERAL 122

This behaviour is making it impossible to write a correct colorizer for regular expressions using the sre_parse module from Python 3.7. I'm not a regex expert, so I cannot say wether this change has any effect on the matching itself, but if I trust regex101, it will add a capturing group in the place of the non-capturing group.

----------
components: Regular Expressions
messages: 405327
nosy: ezio.melotti, mrabarnett, tristanlatr
priority: normal
severity: normal
status: open
title: From Python 3.7, sre_parse.parse() do not create SubPattern instances that can be used to back reproduce original expression if containing non-capturing groups
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 29 15:26:00 2021
From: report at bugs.python.org (Matt Wozniski)
Date: Fri, 29 Oct 2021 19:26:00 +0000
Subject: [New-bugs-announce] [issue45675] pkgutil.get_data() doesn't add
 subpackages to namespaces when importing
Message-ID: <1635535560.24.0.0921518602941.issue45675@roundup.psfhosted.org>


New submission from Matt Wozniski <godlygeek at gmail.com>:

If a module hasn't yet been imported, `pkgutil.get_data(pkg_name, data_file)` will import it, but when it does, it doesn't add the submodule to its parent package when the parent package is a PEP 420 implicit namespace package.

```
$ mkdir -p namespace/package
$ touch namespace/package/__init__.py
$ echo data >namespace/package/data_file
$ python3.10 -c 'import namespace.package, pkgutil; print(pkgutil.get_data("namespace.package", "data_file")); import namespace; print(namespace.package)'
b'data\n'
<module 'namespace.package' from '/tmp/namespace/package/__init__.py'>
$ python3.10 -c 'import pkgutil; print(pkgutil.get_data("namespace.package", "data_file")); import namespace.package; import namespace; print(namespace.package)'
b'data\n'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: module 'namespace' has no attribute 'package'
$
```

In this reproducer, we've got an implicit namespace package called "namespace" and a regular package inside it called "namespace.package". The regular package has a data file called "data_file".

If we import the regular package and then call pkgutil.get_data() to access the data file, it successfully retrieves the data file, and the module object for the namespace package winds up with an attribute referencing the module object for the regular package.

If we call pkgutil.get_data() to access the data file before importing the regular package, it successfully retrieves the data file, but the module object for the namespace package doesn't have an attribute referencing the module object for the regular package, even if we later do a normal import for the regular package.

It looks like pkgutil is importing the module when it hasn't already been imported (which I would expect) and adding it and any parent packages to sys.modules (which I would also expect), but then not adding submodules as attributes to their parent modules like `import` would (which seems like a bug).

----------
components: Library (Lib)
messages: 405331
nosy: godlygeek, pablogsal
priority: normal
severity: normal
status: open
title: pkgutil.get_data() doesn't add subpackages to namespaces when importing
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 29 15:47:03 2021
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 29 Oct 2021 19:47:03 +0000
Subject: [New-bugs-announce] [issue45676] Enum: improve generics support
Message-ID: <1635536823.79.0.358322151332.issue45676@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee: ethan.furman
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Enum: improve generics support
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Oct 29 17:55:04 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Fri, 29 Oct 2021 21:55:04 +0000
Subject: [New-bugs-announce] [issue45677] [doc] improve sqlite3 docs
Message-ID: <1635544504.5.0.82834028892.issue45677@roundup.psfhosted.org>


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

The sqlite3 docs could need a little makeover. Here's some things that could be improved:

- avoid addressing the reader as "you"
- avoid using affirmative tone
- establish a "Security Considerations" or "Common Mistakes" section, instead of littering the docs with warnings


See also:
- https://devguide.python.org/documenting/#style-guide

----------
assignee: docs at python
components: Documentation
messages: 405349
nosy: docs at python, erlendaasland
priority: normal
severity: normal
status: open
title: [doc] improve sqlite3 docs
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Oct 30 08:10:31 2021
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 30 Oct 2021 12:10:31 +0000
Subject: [New-bugs-announce] [issue45678] `functools.singledispatchmethod`
 is missing tests
Message-ID: <1635595831.41.0.152210084078.issue45678@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

`test_functools` includes a test to check that `functools.singledispatch` correctly wraps the attributes of the target function. However, there is no equivalent test for `functools.singledispatchmethod`. There should be, as this is done separately in the `__get__` method of `functools.singledispatchmethod`; it is a different mechanism to `functools.singledispatch`.

Additionally, `test_abstractmethod_register` tests that the return value of `singledispatchmethod.__get__` wraps the target function's `__isabstractmethod__` attribute. However, the `__isabstractmethod__` property of the `singledispatchmethod` class is untested.

----------
components: Library (Lib)
messages: 405366
nosy: AlexWaygood, lukasz.langa, rhettinger
priority: normal
severity: normal
status: open
title: `functools.singledispatchmethod` is missing tests
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Oct 30 11:33:26 2021
From: report at bugs.python.org (Van Burgerberg)
Date: Sat, 30 Oct 2021 15:33:26 +0000
Subject: [New-bugs-announce] [issue45679] typing.Literal[True] is implicitly
 converted to typing.Literal[1]
Message-ID: <1635608006.78.0.966278676499.issue45679@roundup.psfhosted.org>


New submission from Van Burgerberg <vanburgerberg at yandex.ru>:

When you create `Literal[1]` annotation and then create `Literal[True]` annotation, in the second case you will actually get `Literal[1]` instead. This is happening because `typing` performs caching of the outcome of parameterizing generics and `hash(True)` is equal to `hash(1)`. I think this behavior is incorrect and may lead to unexpected results.

Why is this inaccuracy important?
Consider the following example:

```python
from typing import Literal

SomeUsefulAlias = Literal[1, "abc"]

def func(arg: Literal[True, "abc"]):
    if arg is not True:
        arg.capitalize()
```

If we look at `func.__annotations__["arg"]`, we will see `Literal[1, 'abc']`. According to the new annotation, we can pass the value `1` to `func`, and this will lead to an attribute error, as you've already understood. Thus, proper runtime type checking cannot be performed.

----------
components: Library (Lib)
messages: 405371
nosy: vanburgerberg
priority: normal
severity: normal
status: open
title: typing.Literal[True] is implicitly converted to typing.Literal[1]
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 30 16:21:29 2021
From: report at bugs.python.org (Alex Waygood)
Date: Sat, 30 Oct 2021 20:21:29 +0000
Subject: [New-bugs-announce] [issue45680] Documentation on `GenericAlias`
 objects could be improved
Message-ID: <1635625289.5.0.271626210533.issue45680@roundup.psfhosted.org>


New submission from Alex Waygood <Alex.Waygood at Gmail.com>:

The documentation on `GenericAlias` objects implies at multiple points that only container classes can implement `__class_getitem__`, and goes into very little detail about what it means for a non-container class to be parameterized.

----------
assignee: docs at python
components: Documentation
messages: 405384
nosy: AlexWaygood, docs at python, gvanrossum, kj, lukasz.langa
priority: normal
severity: normal
status: open
title: Documentation on `GenericAlias` objects could be improved
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Oct 31 08:12:02 2021
From: report at bugs.python.org (Gabe)
Date: Sun, 31 Oct 2021 12:12:02 +0000
Subject: [New-bugs-announce] [issue45681] tkinter breaks on high resolution
 screen after ctypes SetProcessDPIAware()
Message-ID: <1635682322.33.0.130393544113.issue45681@roundup.psfhosted.org>


New submission from Gabe <gabe.millikan at gmail.com>:

In the following code: 
```py
import tkinter as tk
from tkinter import ttk

import ctypes
ctypes.windll.user32.SetProcessDPIAware()

w = tk.Tk()
ttk.Checkbutton(w, text = "Checkbox").grid()
w.mainloop()
```

The checkbox begins as normal size, but after hovering over it, it becomes small. See attached gif.

The issue does not occur without the SetProcessDPIAware call. 

I am running Windows 11, and my screen resolution is 2560x1440. My Settings>System>Display>Custom Scaling is set to 150%. I believe that this is relevant because SetProcessDPIAware() directly affects the dpi awareness (aka 'custom scaling') of the program, according to Microsoft documentation.

----------
components: Tkinter
files: KwUqCTWl58.gif
messages: 405401
nosy: GabeMillikan
priority: normal
severity: normal
status: open
title: tkinter breaks on high resolution screen after ctypes SetProcessDPIAware()
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50413/KwUqCTWl58.gif

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

From report at bugs.python.org  Sun Oct 31 09:55:19 2021
From: report at bugs.python.org (Olaf van der Spek)
Date: Sun, 31 Oct 2021 13:55:19 +0000
Subject: [New-bugs-announce] [issue45682] Nicer default logging format
Message-ID: <1635688519.79.0.666388517384.issue45682@roundup.psfhosted.org>


New submission from Olaf van der Spek <olafvdspek at gmail.com>:

The default logging format will print something like: 
WARNING:root:Hello Python!

Could it default to something like this instead?

2021-10-31 14:52:36,490 WARNING: Hello Python!

logging.basicConfig(format='%(asctime)s %(levelname)s: %(message)s')
logging.warning('Hello Python!')

----------
components: Library (Lib)
messages: 405403
nosy: olafvdspek
priority: normal
severity: normal
status: open
title: Nicer default logging format
type: enhancement

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