From report at bugs.python.org  Tue Mar  1 04:38:30 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Mar 2022 09:38:30 +0000
Subject: [New-bugs-announce] [issue46887] ./Programs/_freeze_module fails
 with MSAN: Uninitialized value was created by an allocation of 'stat.i'
Message-ID: <1646127510.42.0.802803841072.issue46887@roundup.psfhosted.org>


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

"./Programs/_freeze_module zipimport" fails with MSAN:
---
$ make SHELL="bash -x"
(...)
+ ./Programs/_freeze_module zipimport ./Lib/zipimport.py Python/frozen_modules/zipimport.h
==110524==WARNING: MemorySanitizer: use-of-uninitialized-value
==110523==WARNING: MemorySanitizer: use-of-uninitialized-value
==110526==WARNING: MemorySanitizer: use-of-uninitialized-value
==110525==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4b8cfc in read_text /home/vstinner/python/main/Programs/_freeze_module.c:109:9
    #1 0x4b8cfc in main /home/vstinner/python/main/Programs/_freeze_module.c:224:24
    #2 0x7fe8acb8555f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    #3 0x7fe8acb8560b in __libc_start_main at GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
    #4 0x435f44 in _start (/home/vstinner/python/main/Programs/_freeze_module+0x435f44)

  Uninitialized value was created by an allocation of 'stat.i' in the stack frame of function 'main'
    #0 0x4b72e0 in main /home/vstinner/python/main/Programs/_freeze_module.c:205

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vstinner/python/main/Programs/_freeze_module.c:109:9 in read_text
Exiting
make: *** [Makefile:1184: Python/frozen_modules/importlib._bootstrap_external.h] Error 1
make: *** Waiting for unfinished jobs....
    #0 0x4b8cfc in read_text /home/vstinner/python/main/Programs/_freeze_module.c:109:9
    #1 0x4b8cfc in main /home/vstinner/python/main/Programs/_freeze_module.c:224:24
    #2 0x7f64ecd1355f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    #3 0x7f64ecd1360b in __libc_start_main at GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
    #4 0x435f44 in _start (/home/vstinner/python/main/Programs/_freeze_module+0x435f44)

  Uninitialized value was created by an allocation of 'stat.i' in the stack frame of function 'main'
    #0 0x4b72e0 in main /home/vstinner/python/main/Programs/_freeze_module.c:205

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vstinner/python/main/Programs/_freeze_module.c:109:9 in read_text
Exiting
make: *** [Makefile:1176: Python/frozen_modules/getpath.h] Error 1
    #0 0x4b8cfc in read_text /home/vstinner/python/main/Programs/_freeze_module.c:109:9
    #1 0x4b8cfc in main /home/vstinner/python/main/Programs/_freeze_module.c:224:24
    #2 0x7fb2a178d55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    #3 0x7fb2a178d60b in __libc_start_main at GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
    #4 0x435f44 in _start (/home/vstinner/python/main/Programs/_freeze_module+0x435f44)

    #0 0x4b8cfc in read_text /home/vstinner/python/main/Programs/_freeze_module.c:109:9
    #1 0x4b8cfc in main /home/vstinner/python/main/Programs/_freeze_module.c:224:24
    #2 0x7f4d471ca55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    #3 0x7f4d471ca60b in __libc_start_main at GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
    #4 0x435f44 in _start (/home/vstinner/python/main/Programs/_freeze_module+0x435f44)

  Uninitialized value was created by an allocation of 'stat.i' in the stack frame of function 'main'
  Uninitialized value was created by an allocation of 'stat.i' in the stack frame of function 'main'
    #0 0x4b72e0 in main /home/vstinner/python/main/Programs/_freeze_module.c:205

    #0 0x4b72e0 in main /home/vstinner/python/main/Programs/_freeze_module.c:205

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vstinner/python/main/Programs/_freeze_module.c:109:9 in read_text
SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/vstinner/python/main/Programs/_freeze_module.c:109:9 in read_text
Exiting
Exiting
make: *** [Makefile:1181: Python/frozen_modules/importlib._bootstrap.h] Error 1
make: *** [Makefile:1187: Python/frozen_modules/zipimport.h] Error 1
---

Build Python with clang MSAN:
---
./configure --with-pydebug --with-memory-sanitizer CC=clang LD=clang
make
---

----------
components: Build
messages: 414249
nosy: vstinner
priority: normal
severity: normal
status: open
title: ./Programs/_freeze_module fails with MSAN: Uninitialized value was created by an allocation of 'stat.i'
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 06:39:08 2022
From: report at bugs.python.org (Ronny Rentner)
Date: Tue, 01 Mar 2022 11:39:08 +0000
Subject: [New-bugs-announce] [issue46888] SharedMemory.close() destroys
 memory
Message-ID: <1646134748.49.0.513958523413.issue46888@roundup.psfhosted.org>


New submission from Ronny Rentner <python at ronny-rentner.de>:

According to https://docs.python.org/3/library/multiprocessing.shared_memory.html#multiprocessing.shared_memory.SharedMemory.close if I call close() on a shared memory, it shall not be destroyed.

Unfortunately this is only true for Linux but not for Windows.

I've tested this in a Windows VM on VirtualBox like this:

```
Python 3.10.2 (tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing.shared_memory
>>> creator = multiprocessing.shared_memory.SharedMemory(create=True, name='mymemory', size=10000)
>>> creator.buf[0] = 1
>>> creator.buf[0]
1
>>> # According to  close() is supposed to not destroy 'mymemory' but it does destroy it.
>>> creator.close()
>>>
>>> user = multiprocessing.shared_memory.SharedMemory(name='mymemory')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\User\AppData\Local\Programs\Python\Python310\lib\multiprocessing\shared_memory.py", line 161, in __init__
    h_map = _winapi.OpenFileMapping(
FileNotFoundError: [WinError 2] The system cannot find the file specified: 'mymemory'
>>> # Shared memory was destroyed by close()
```

----------
components: Windows
messages: 414258
nosy: paul.moore, ronny-rentner, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: SharedMemory.close() destroys memory
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  1 10:18:14 2022
From: report at bugs.python.org (lyinch)
Date: Tue, 01 Mar 2022 15:18:14 +0000
Subject: [New-bugs-announce] [issue46889] enable sqlite math functions on
 macos
Message-ID: <1646147894.62.0.324206137602.issue46889@roundup.psfhosted.org>


New submission from lyinch <lyinch at lyinch.com>:

Similar to these PRs: https://github.com/python/cpython/pull/24053/files and https://github.com/python/cpython/pull/25892/files which enable the built-in sqlite3 math functions for Windows, I want to have support for them on macos. As per the sqlite3 documentation: https://sqlite.org/releaselog/3_35_0.html this requires compilation with -DSQLITE_ENABLE_MATH_FUNCTIONS . On master, the flag is missing for macos : https://github.com/python/cpython/blob/main/Mac/BuildScript/build-installer.py#L364

----------
components: Library (Lib), macOS
messages: 414272
nosy: lyinch, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: enable sqlite math functions on macos
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 11:25:46 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Mar 2022 16:25:46 +0000
Subject: [New-bugs-announce] [issue46890] vent does not create "python" link
 in python 3.11
Message-ID: <1646151946.28.0.599042990928.issue46890@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

In python3.10 and earlier "python3 -m venv something" creates "something/bin/python" as a symlink to the interpreter itself.

In python3.11 (a5) the same command no longer creates "something/bin/python", but only the ".../python3" symlink. 

With this change the "python" command no longer refers to the interpreter in an activated virtualenv, but to a different binary on $PATH (if any).

I tested using the Python 3.11a5 installer for macOS on python.org.

----------
components: Library (Lib)
keywords: 3.11regression
messages: 414278
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: vent does not create "python" link in python 3.11
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 16:25:06 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Mar 2022 21:25:06 +0000
Subject: [New-bugs-announce] [issue46891] Crash in ModuleType subclass with
 __slots__
Message-ID: <1646169906.66.0.789674820049.issue46891@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The following crashes the interpreter in Python 3.11, and works fine in older versions:

# --- script.py 
import types

class MyModule (types.ModuleType):
    __slots__ = (
        "_MyModule__a",
        "_MyModule__b",
    )

    def __init__(self, name):
        super().__init__(name)

m = MyModule("name")
# -- end of file

The key in this is the ``__slots__`` definition: The script does not crash without ``__slots__``, or with a slots tuple with 1 item.

This is a reproducer based on code in PyObjC.

----------
components: Interpreter Core
keywords: 3.11regression
messages: 414294
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Crash in ModuleType subclass with __slots__
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 17:13:38 2022
From: report at bugs.python.org (Matt Page)
Date: Tue, 01 Mar 2022 22:13:38 +0000
Subject: [New-bugs-announce] [issue46892] Async Call-Stack Reconstruction
Message-ID: <1646172818.87.0.620414144341.issue46892@roundup.psfhosted.org>


New submission from Matt Page <mpage at cs.stanford.edu>:

Profiling tools that use the call-stack (i.e. all of them) paint an incomplete picture of what?s really going on in async-heavy codebases. They can only show the stack of the currently executing task; they miss the chain of awaitables that are transitively waiting on the current task. To remedy this, we have added support in Cinder to expose the async call-stack. This consists of the call stack for the currently executing task, followed by the chain of awaitables that are transitively reachable from the currently executing task. See below for a clarifying example.

```
async def f1():
  return await f2()

async def f2():
  return await asyncio.ensure_future(f3())

async def f3():
  return await f4()

async def f4():
  await asyncio.sleep(10)
  return 42
```

When retrieved from f4, the two different stacks (top-of-stack last) are:
sync - [f3, f4]
async - [f1, f2, f3, f4] 


We?d like to merge our implementation into CPython so that other heavy users of asyncio can benefit. This will consist of a few parts:

1. A new limited C-API to set and retrieve the ?awaiter? of an awaitable object.
2. Additions to PyAsyncMethods to store function pointers for setting and retrieving the awaiter on instances.
3. An API in managed code to retrieve the async call stack as a list of fully qualified names (i.e. <module>:<class>.<function>).

----------
components: Interpreter Core, asyncio
messages: 414301
nosy: asvetlov, dino.viehland, itamaro, mpage, yselivanov
priority: normal
severity: normal
status: open
title: Async Call-Stack Reconstruction
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 17:14:02 2022
From: report at bugs.python.org (Itamar Ostricher)
Date: Tue, 01 Mar 2022 22:14:02 +0000
Subject: [New-bugs-announce] [issue46893] Allow extensions to set the
 vectorcall field on instances of PyFunctionObject
Message-ID: <1646172842.87.0.805036575414.issue46893@roundup.psfhosted.org>


New submission from Itamar Ostricher <itamarost at gmail.com>:

CPython extensions providing optimized execution of Python bytecode (like [Cinder JIT](https://docs.google.com/document/d/1l8I-FDE1xrIShm9eSNJqsGmY_VanMDX5-aK_gujhYBI/edit#heading=h.ujldakarfxhh) and [Pyjion](https://github.com/tonybaloney/Pyjion))
can benefit from being able to modify the vectorcall field on instances of PyFunctionObject to allow calling the optimized path (e.g. JIT-compiled) directly.

We propose adding an API to allow extensions to override this field:

```
void PyFunction_SetVectorcall(PyFunctionObject *func, vectorcallfunc vectorcall);
```

----------
components: Interpreter Core
messages: 414302
nosy: carljm, dino.viehland, itamaro
priority: normal
severity: normal
status: open
title: Allow extensions to set the vectorcall field on instances of PyFunctionObject
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 17:16:00 2022
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Tue, 01 Mar 2022 22:16:00 +0000
Subject: [New-bugs-announce] [issue46894] make install DESTDIR= uses
 /lib/python3.10/lib-dynload out of DESTDIR
Message-ID: <1646172960.85.0.550744633196.issue46894@roundup.psfhosted.org>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

With most recent 3.10 (v3.10.2-169-g98e2ee60) I call

./configure --prefix=/  && make && make DESTDIR=/home/d/A install

It fails with:

running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_gdbm                 _tkinter              nis                
readline                                                       
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  pwd                   time               

running build_scripts
copying and adjusting /git/cpython/Tools/scripts/pydoc3 -> build/scripts-3.10
copying and adjusting /git/cpython/Tools/scripts/idle3 -> build/scripts-3.10
copying and adjusting /git/cpython/Tools/scripts/2to3 -> build/scripts-3.10
changing mode of build/scripts-3.10/pydoc3 from 644 to 755
changing mode of build/scripts-3.10/idle3 from 644 to 755
changing mode of build/scripts-3.10/2to3 from 644 to 755
renaming build/scripts-3.10/pydoc3 to build/scripts-3.10/pydoc3.10
renaming build/scripts-3.10/idle3 to build/scripts-3.10/idle3.10
renaming build/scripts-3.10/2to3 to build/scripts-3.10/2to3-3.10
running install_lib
creating /lib/python3.10/lib-dynload
error: could not create '/lib/python3.10/lib-dynload': Permission denied
make: *** [Makefile:1761: sharedinstall] Error 1

----------
components: Build
messages: 414303
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: make install DESTDIR=  uses /lib/python3.10/lib-dynload out of DESTDIR
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  1 17:16:51 2022
From: report at bugs.python.org (Matt Page)
Date: Tue, 01 Mar 2022 22:16:51 +0000
Subject: [New-bugs-announce] [issue46895] Type-Modified Callbacks
Message-ID: <1646173011.06.0.919834153407.issue46895@roundup.psfhosted.org>


New submission from Matt Page <mpage at cs.stanford.edu>:

CPython extensions providing optimized execution of Python bytecode (e.g. the Cinder JIT), or even CPython itself (e.g. the faster-cpython project) may wish to cache access to lookups in the class hierarchy (e.g. when resolving the target of a method call). Extensions that perform these optimizations need to know when to invalidate the cached values. CPython already has a mechanism to invalidate its internal state (e.g. the global method cache) when a type is modified: _PyType_Modified. We propose adding an API to allow extensions to set a callback that will be invoked by _PyType_Modified whenever a type, or any ancestor of the type in the class hierarchy, changes.

Proposed API:

```
// A callback to be invoked with the modified type and optionally the name of
// the attribute that was modified.
typedef void(*PyType_ModifiedCallback)(PyTypeObject* type, PyObject* attr);

// Set or get the callback. The callback may be cleared by supplying a NULL callback.
void PyType_SetModifiedCallback(PyType_ModifiedCallback callback);
PyType_ModifiedCallback PyType_GetModifiedCallback();
```

----------
components: C API, Interpreter Core
messages: 414305
nosy: carljm, dino.viehland, itamaro, mpage
priority: normal
severity: normal
status: open
title: Type-Modified Callbacks
type: enhancement

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

From report at bugs.python.org  Tue Mar  1 17:19:05 2022
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 01 Mar 2022 22:19:05 +0000
Subject: [New-bugs-announce] [issue46896] add support for watching writes to
 selecting dictionaries
Message-ID: <1646173145.14.0.810360820171.issue46896@roundup.psfhosted.org>


New submission from Carl Meyer <carl at oddbird.net>:

CPython extensions providing optimized execution of Python bytecode (e.g. the Cinder JIT), or even CPython itself (e.g. the faster-cpython project) may wish to inline-cache access to frequently-read and rarely-changed namespaces, e.g. module globals. Rather than requiring a dict version guard on every cached read, the best-performing way to do this is is to mark the dictionary as ?watched? and set a callback on writes to watched dictionaries. This optimizes the cached-read fast-path at a small cost to the (relatively infrequent and usually less perf sensitive) write path.

We have an implementation of this in Cinder ( https://docs.google.com/document/d/1l8I-FDE1xrIShm9eSNJqsGmY_VanMDX5-aK_gujhYBI/edit#heading=h.n2fcxgq6ypwl ), used already by the Cinder JIT and its specializing interpreter. We would like to make the Cinder JIT available as a third-party extension to CPython ( https://docs.google.com/document/d/1l8I-FDE1xrIShm9eSNJqsGmY_VanMDX5-aK_gujhYBI/ ), and so we are interested in adding dict watchers to core CPython.

The intention in this issue is not to add any specific optimization or cache (yet); just the ability to mark a dictionary as ?watched? and set a write callback.

The callback will be global, not per-dictionary (no extra function pointer stored in every dict). CPython will track only one global callback; it is a well-behaved client?s responsibility to check if a callback is already set when setting a new one, and daisy-chain to the previous callback if so. Given that multiple clients may mark dictionaries as watched, a dict watcher callback may receive events for dictionaries that were marked as watched by other clients, and should handle this gracefully.

There is no provision in the API for ?un-watching? a watched dictionary; such an API could not be used safely in the face of potentially multiple dict-watching clients.

The Cinder implementation marks dictionaries as watched using the least bit of the dictionary version (so version increments by 2); this also avoids any additional memory usage for marking a dict as watched.

Initial proposed API, comments welcome:

// Mark given dictionary as "watched" (global callback will be called if it is modified)
void PyDict_Watch(PyObject* dict);

// Check if given dictionary is already watched
int PyDict_IsWatched(PyObject* dict);

typedef enum {
  PYDICT_EVENT_CLEARED,
  PYDICT_EVENT_DEALLOCED,
  PYDICT_EVENT_MODIFIED
} PyDict_WatchEvent;

// Callback to be invoked when a watched dict is cleared, dealloced, or modified.
// In clear/dealloc case, key and new_value will be NULL. Otherwise, new_value will be the
// new value for key, NULL if key is being deleted.
typedef void(*PyDict_WatchCallback)(PyDict_WatchEvent event, PyObject* dict, PyObject* key, PyObject* new_value);

// Set new global watch callback; supply NULL to clear callback
void PyDict_SetWatchCallback(PyDict_WatchCallback callback);

// Get existing global watch callback
PyDict_WatchCallback PyDict_GetWatchCallback();

The callback will be called immediately before the modification to the dict takes effect, thus the callback will also have access to the prior state of the dict.

----------
components: C API
messages: 414307
nosy: carljm, dino.viehland, itamaro
priority: normal
severity: normal
status: open
title: add support for watching writes to selecting dictionaries
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 17:19:44 2022
From: report at bugs.python.org (Matt Page)
Date: Tue, 01 Mar 2022 22:19:44 +0000
Subject: [New-bugs-announce] [issue46897] Add API to allow extensions to set
 callback function on creation, modification,
 and destruction of PyFunctionObject
Message-ID: <1646173184.63.0.558173732938.issue46897@roundup.psfhosted.org>


New submission from Matt Page <mpage at cs.stanford.edu>:

CPython extensions providing optimized execution of Python bytecode (e.g. the Cinder JIT) may need to hook into the lifecycle of function objects to determine what to optimize, invalidate previously-optimized functions, or free resources allocated for functions that no longer exist. For example, when inlining a function, the Cinder JIT will use the bytecode of the inlined function that was known at compile-time. If the bytecode for the inlined function changes at runtime (i.e. if __code__ was reassigned) the JIT needs to invalidate any code into which the function was inlined. We propose adding an API to allow extensions to set callbacks that will be invoked whenever functions are created, modified, or destroyed.

Proposed API:

```
typedef enum {
  PYFUNC_LCEVT_CREATED,
  PYFUNC_LCEVT_MODIFIED,
  PYFUNC_LCEVT_DESTROYED
} PyFunction_LifecycleEvent;

typedef enum {
  PYFUNC_ATTR_CODE,
  PYFUNC_ATTR_GLOBALS,
  PYFUNC_ATTR_DEFAULTS,
  PYFUNC_ATTR_KWDEFAULTS,
  PYFUNC_ATTR_CLOSURE,
  PYFUNC_ATTR_NOT_APPLICABLE,
} PyFunction_AttrId;

// A callback to be called in response to events in a function's lifecycle.
//
// The callback is invoked after a function is created and before the function 
// is modified or destroyed.
//
// On modification the third argument indicates which attribute was modified
// and the fourth argument is the new value.
// Otherwise the third argument is PYFUNC_ATTR_NOT_APPLICABLE and the fourth
// argument is NULL.
typedef void(*PyFunction_LifecycleCallback)(
  PyFunction_LifecycleEvent event, 
  PyFunctionObject* func,
  PyFunction_AttrId attr,
  PyObject* new_value);

void PyFunction_SetLifecycleCallback(PyFunction_LifecycleCallback callback);
PyFunction_LifecycleCallback PyFunction_GetLifecycleCallback();
```

----------
components: C API
messages: 414308
nosy: carljm, dino.viehland, itamaro, mpage
priority: normal
severity: normal
status: open
title: Add API to allow extensions to set callback function on creation, modification, and destruction of PyFunctionObject
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 17:20:58 2022
From: report at bugs.python.org (Matt Page)
Date: Tue, 01 Mar 2022 22:20:58 +0000
Subject: [New-bugs-announce] [issue46898] Add API to allow extensions to set
 callback function on creation and destruction of PyCodeObject
Message-ID: <1646173258.53.0.415525425157.issue46898@roundup.psfhosted.org>


New submission from Matt Page <mpage at cs.stanford.edu>:

CPython extensions providing optimized execution of Python bytecode (e.g. the Cinder JIT) may need to hook into the lifecycle of code objects to determine what to optimize or to free resources allocated for code objects that no longer exist. We propose adding an API to allow extensions to set callbacks that will be invoked whenever code objects are created or destroyed.

Proposed API:

```
typedef enum {
  PYCODE_LCEVT_CREATED,
  PYCODE_LCEVT_DESTROYED
} PyCode_LifecycleEvent;

// A callback to be called when a code object is created or about to be destroyed.
typedef void(*PyCode_LifecycleCallback)(
  PyCode_LifecycleEvent event,
  PyCodeObject* code);

void PyCode_SetLifecycleCallback(PyCode_LifecycleCallback callback);
PyCode_LifecycleCallback PyCode_GetLifecycleCallback();

```

----------
components: C API
messages: 414309
nosy: carljm, dino.viehland, itamaro, mpage
priority: normal
severity: normal
status: open
title: Add API to allow extensions to set callback function on creation and destruction of PyCodeObject
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  1 19:48:44 2022
From: report at bugs.python.org (Yilei Yang)
Date: Wed, 02 Mar 2022 00:48:44 +0000
Subject: [New-bugs-announce] [issue46899] use of uninitialized value with
 msan from subprocess_fork_exec
Message-ID: <1646182124.68.0.0216044317389.issue46899@roundup.psfhosted.org>


New submission from Yilei Yang <yileiyang9 at gmail.com>:

The uid & gid variable from https://github.com/python/cpython/blob/9833bb91e4d5c2606421d9ec2085f5c2dfb6f72c/Modules/_posixsubprocess.c#L737-L738 can be passed to the `do_fork_exec` call below uninitialized and cause msan to report use-of-uninitialized-value errors.

Those variables are guarded by call_setgid/call_setuid so they aren't really used uninitialized in practice. It would just be great if we can make it msan clean.

Ideally, the long list of do_fork_exec arguments could also be rewritten in a struct.

----------
components: Library (Lib)
messages: 414320
nosy: gregory.p.smith, yilei
priority: normal
severity: normal
status: open
title: use of uninitialized value with msan from subprocess_fork_exec
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Mar  2 09:40:17 2022
From: report at bugs.python.org (William Dreese)
Date: Wed, 02 Mar 2022 14:40:17 +0000
Subject: [New-bugs-announce] [issue46900] marshal.dumps represents the same
 list object differently
Message-ID: <1646232017.23.0.623860901093.issue46900@roundup.psfhosted.org>


New submission from William Dreese <wdreese123 at gmail.com>:

Hello,

I've been working with the marshal package and came across this issue (I think) -

Python 3.9.10 Interpreter
(Same output in 3.11.0a5+ (heads/master:b6b711a1aa) on darwin)
>>> import marshal
>>> var_example = [(1,2,3),(4,5,6)]
>>> var_marshaled = marshal.dumps(var_example)
>>> raw_marshaled = marshal.dumps([(1,2,3),(4,5,6)])
>>> def pp(to_print):
>>>     [print(byt) for byt in to_print]
>>> pp(var_marshaled)
219
2
0
0
0
41
3
233
1
0
0
0
233
2
0
0
0
233
3
0
0
0
169
3
233
4
0
0
0
233
5
0
0
0
233
6
0
0
0
91
2
0
0
0
41
3
233
1
0
0
0
233
2
0
0
0
233
3
0
0
0
169
3
233
4
0
0
0
233
5
0
0
0
233
6
0
0
0
>>> pp(raw_marshaled)
219
2
0
0
0
169
3
233
1
0
0
0
233
2
0
0
0
233
3
0
0
0
169
3
233
4
0
0
0
233
5
0
0
0
233
6
0
0
0
91
2
0
0
0
169
3
233
1
0
0
0
233
2
0
0
0
233
3
0
0
0
169
3
233
4
0
0
0
233
5
0
0
0
233
6
0
0
0

The difference above lies in the byte representation of the tuple type (41 in the variable version and 169 in the raw version). Is this intended behavior?

----------
components: C API
messages: 414362
nosy: Dreeseaw
priority: normal
severity: normal
status: open
title: marshal.dumps represents the same list object differently
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar  2 12:45:33 2022
From: report at bugs.python.org (Ned Deily)
Date: Wed, 02 Mar 2022 17:45:33 +0000
Subject: [New-bugs-announce] [issue46901] Deprecate and eventually remove
 macOS-only PYTHONEXECUTABLE environ variable
Message-ID: <1646243133.81.0.36417980117.issue46901@roundup.psfhosted.org>


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

The PYTHONEXECUTABLE is a holdover from old Python 2 days; AFAIK, it was specifically to support the Build Applet tool which could be used to build macOS app bundles in Python 2. The only place in current Py3 releases where it is used is in the standard library is in the launch of IDLE.app, a usage that should be able to be eliminated. Otherwise, there shouldn't be any need for it by third-parties.  For 3.11, we could eliminate its use by IDLE.app and add a deprecation warning to the docs; not sure about an execution time warning?

https://docs.python.org/3/using/cmdline.html#envvar-PYTHONEXECUTABLE

----------
assignee: docs at python
components: Documentation, macOS
messages: 414382
nosy: docs at python, ned.deily, ronaldoussoren, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate and eventually remove macOS-only PYTHONEXECUTABLE environ variable
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar  2 15:42:20 2022
From: report at bugs.python.org (Jean Abou Samra)
Date: Wed, 02 Mar 2022 20:42:20 +0000
Subject: [New-bugs-announce] [issue46902] Typo hint message for from-imports?
Message-ID: <1646253740.47.0.0857433223872.issue46902@roundup.psfhosted.org>


New submission from Jean Abou Samra <jean at abou-samra.fr>:

See for example:

>>> from pygments.regexopt import regexopt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'regexopt' from 'pygments.regexopt' (/home/jean/repos/pygments/pygments/regexopt.py)
>>> from pygments.regexopt import regex_opt
>>> regexopt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'regexopt' is not defined. Did you mean: 'regex_opt'?

In Python 3.10, there is a nice helpful error message suggesting
how to correct the typo for NameError and AttributeError. Would
it be possible to have the same for ImportError with 'from import'?

----------
components: Interpreter Core
messages: 414385
nosy: Jean_Abou_Samra
priority: normal
severity: normal
status: open
title: Typo hint message for from-imports?
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Mar  2 16:30:36 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Mar 2022 21:30:36 +0000
Subject: [New-bugs-announce] [issue46903] Crash when setting attribute with
 string subclass as the name (--with-pydebug)
Message-ID: <1646256636.59.0.442198647439.issue46903@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The script below fails with an assertion error with python 3.11a5+ (current trunk) when build with --with-pydebug:

# BEGIN OF FILE
class String(str):
    __slots__ = ()

name = String("hello")

class Bag:
    pass

o = Bag()
setattr(o, name, 42)

# END OF FILE

Error output:

% /tmp/py311/bin/python3 -Xdev str.py                                                                                                                 (master)pyobjc-8
Assertion failed: (PyUnicode_CheckExact(name)), function _PyObject_StoreInstanceAttribute, file dictobject.c, line 5426.
Fatal Python error: Aborted

Current thread 0x0000000100a98580 (most recent call first):
  File "/Users/ronald/Projects/pyobjc-8/pyobjc-core/str.py", line 10 in <module>
zsh: abort      /tmp/py311/bin/python3 -Xdev str.py

----------
components: Interpreter Core
messages: 414386
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Crash when setting attribute with string subclass as the name (--with-pydebug)
type: crash
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar  2 18:39:52 2022
From: report at bugs.python.org (Constantine Evans)
Date: Wed, 02 Mar 2022 23:39:52 +0000
Subject: [New-bugs-announce] [issue46904] Python Decimal supports '#' format,
 C Decimal does not.
Message-ID: <1646264392.01.0.522229307506.issue46904@roundup.psfhosted.org>


New submission from Constantine Evans <const at costi.eu>:

Decimal as implemented in _pydecimal supports the '#' alternate form in format strings, though this does not appear to be documented: as with floats, it causes a decimal point to be included regardless of value.  Decimal as implemented in cdecimal, as it uses libmpdec, does not.

This is a rather minor discrepancy; I hadn't actually intended to have # in my format string at all, but it had ended up there and was causing errors for half of the users of my library.  # also could be useful for decimals, as it can be for floats.

Like #45739, it's unclear to me whether this is a discrepancy that should be corrected by implementing # for cdecimal, removing # support for _pydecimal, or just documenting the inconsistency.

----------
components: Library (Lib)
messages: 414390
nosy: const
priority: normal
severity: normal
status: open
title: Python Decimal supports '#' format, C Decimal does not.
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed Mar  2 19:02:59 2022
From: report at bugs.python.org (Julian)
Date: Thu, 03 Mar 2022 00:02:59 +0000
Subject: [New-bugs-announce] [issue46905] winsound.PlaySound should accept
 pathlib.Path instances
Message-ID: <1646265779.67.0.979185331042.issue46905@roundup.psfhosted.org>


New submission from Julian <github at somethinkodd.com>:

The library function winsound.PlaySound takes a sound parameter. One of the valid arguments is a path to a WAV filename.

Since Python 3.4, paths can be cleanly represented with PathLib.Path instances.

However, if you pass a Path instance to PlaySound, it responds with:

   TypeError: 'sound' must be str or None, not 'WindowsPath'

This can be quickly fixed in the caller by passing str(the_path_instance) instead, but it would be cleaner if PlaySound accepted Python's preferred method of representing paths.

----------
components: Library (Lib)
messages: 414393
nosy: Julian-O
priority: normal
severity: normal
status: open
title: winsound.PlaySound should accept pathlib.Path instances
type: enhancement

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

From report at bugs.python.org  Wed Mar  2 22:09:32 2022
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 03 Mar 2022 03:09:32 +0000
Subject: [New-bugs-announce] [issue46906] Make _PyFloat_(Pack|Unpack)(4|8)
 cpython API, not internal.
Message-ID: <1646276972.11.0.142101531058.issue46906@roundup.psfhosted.org>


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

Original issue. https://github.com/msgpack/msgpack-python/issues/497

_PyFloat_(Pack|Unpack)(4|8) is very nice API for serializers like msgpack.
Converting double and float into char[] is not trivial and these APIs do it in very efficient way.

And these APIs don't reveal CPython internal strucutre. It just convert double and float into char[].

So please keep these APIs public for libraries like msgpack.

----------
components: C API
messages: 414401
nosy: methane, vstinner
priority: normal
severity: normal
status: open
title: Make _PyFloat_(Pack|Unpack)(4|8) cpython API, not internal.
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar  3 03:27:32 2022
From: report at bugs.python.org (Mariusz Felisiak)
Date: Thu, 03 Mar 2022 08:27:32 +0000
Subject: [New-bugs-announce] [issue46907] Update Windows and MacOS installer
 to SQLite 3.38.0.
Message-ID: <1646296052.93.0.200191354741.issue46907@roundup.psfhosted.org>


New submission from Mariusz Felisiak <felisiak.mariusz at gmail.com>:

SQLite 3.37.0 was released on 2022-02-22: https://sqlite.org/releaselog/3_38_0.html

----------
components: Windows, macOS
messages: 414412
nosy: erlendaasland, felixxm, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update Windows and MacOS installer to SQLite 3.38.0.
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar  3 05:20:54 2022
From: report at bugs.python.org (=?utf-8?q?Francisco_Arenas_Af=C3=A1n_de_Rivera?=)
Date: Thu, 03 Mar 2022 10:20:54 +0000
Subject: [New-bugs-announce] [issue46908] Debugger jumps to a wrong
 instruction in for loop
Message-ID: <1646302854.95.0.25406380974.issue46908@roundup.psfhosted.org>


New submission from Francisco Arenas Af?n de Rivera <franarenasafan at gmail.com>:

I found that the debugger doesn't follow the normal program order when executing a foor loop with more than 3 instructions inside and one loop.

code example:

a = 0
b = 0
c = 0
for i in range(1):
    a += 1
    b += 1 # Set breakpoint here
    c += 1 # Also crash with breakpoint here

jumps to the line b += 1 after the end of the loop and crashes with error: Process finished with exit code -1073741819 (0xC0000005)

----------
messages: 414417
nosy: franarenasafan
priority: normal
severity: normal
status: open
title: Debugger jumps to a wrong instruction in for loop
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar  3 05:53:11 2022
From: report at bugs.python.org (Russel Webber)
Date: Thu, 03 Mar 2022 10:53:11 +0000
Subject: [New-bugs-announce] [issue46909] Update getpath.py to look for
 os.pyc in __pycache__ folders
Message-ID: <1646304791.08.0.433238177633.issue46909@roundup.psfhosted.org>


New submission from Russel Webber <russel at computer.org>:

The STDLIB_LANDMARKS in Modules/getpath,py refers to os.pyc in an old location:
 STDLIB_LANDMARKS = [f'{STDLIB_SUBDIR}/os.py', f'{STDLIB_SUBDIR}/os.pyc']

Since https://www.python.org/dev/peps/pep-3147 the .pyc files are in __pycache__ folders.

The STDLIB_LANDMARKS should be updated.

----------
assignee: docs at python
components: Documentation, Extension Modules, Interpreter Core
messages: 414421
nosy: RusselWebber, docs at python, ned.deily, steve.dower
priority: normal
severity: normal
status: open
title: Update getpath.py to look for os.pyc in __pycache__ folders
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar  3 06:22:08 2022
From: report at bugs.python.org (Jonathan Fine)
Date: Thu, 03 Mar 2022 11:22:08 +0000
Subject: [New-bugs-announce] [issue46910] Expect IndentationError,
 get SyntaxError: 'break' outside loop
Message-ID: <1646306528.93.0.506258424716.issue46910@roundup.psfhosted.org>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

This arises from a request for help made by Nguy?n Ng?c Ti?n to the visually impaired programmers lists, see https://www.freelists.org/post/program-l/python,48. Please keep this in mind.

Nguy?n asked for help with the syntax error created by
===
count = 0
while count < 1:
 count = count + 1
 print(count)
break
 else:
 print("no break")
===

When I saved this to a file and ran it I got:
===
$ python3.8 funny_break_error.py 
  File "funny_break_error.py", line 6
    else:
    ^
IndentationError: unexpected indent
===

However, remove the last two lines and you get the more helpful error
===
$ python3.8 funny_break_error.py 
  File "funny_break_error.py", line 5
    break
    ^
SyntaxError: 'break' outside loop
===

Python3.6 and 3.7 also behave as above.

Note. I've heard that blind Python programmers prefer a single space to denote indent. I think this is because they hear the leading spaces via a screen reader, rather than see the indent with their eyes.

----------
components: Parser
files: funny_break_error.py
messages: 414424
nosy: jfine2358, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Expect IndentationError, get SyntaxError: 'break' outside loop
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file50655/funny_break_error.py

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

From report at bugs.python.org  Thu Mar  3 08:36:59 2022
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 03 Mar 2022 13:36:59 +0000
Subject: [New-bugs-announce] [issue46911] Early tracing has lineno=None for
 modules
Message-ID: <1646314619.94.0.770147890842.issue46911@roundup.psfhosted.org>


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

Coverage.py has a trick to measure the early execution of stdlib modules. It has an "encodings.py" file that sets a trace function, then gets out of the way to let the real encodings.py execute.  In 3.11.0a5, that early trace function gets None values for the line numbers when modules were first executed.

To reproduce, create two files, encodings.py and prog.py:

--- 8< ------------------------------------------
# encodings.py
import sys

class FullCoverageTracer:
    def __init__(self):
        self.traces = []

    def fullcoverage_trace(self, *args):
        frame, event, arg = args
        if frame.f_lineno is None:
            self.traces.append((frame.f_code.co_name, frame.f_code.co_filename))
        return self.fullcoverage_trace

sys.settrace(FullCoverageTracer().fullcoverage_trace)

parentdir = max(filter(__file__.startswith, sys.path), key=len)
sys.path.remove(parentdir)
del sys.modules['encodings']
import encodings
-------------------------------------------------

--- 8< ------------------------------------------
# prog.py
import sys

print(sys.version)
trace = sys.gettrace()
print("None traces:", trace.__self__.traces)
print("Hello")
-------------------------------------------------

Then run:

% PYTHONPATH=$(pwd) python3.10 prog.py
3.10.2 (main, Jan 15 2022, 05:51:59) [Clang 12.0.0 (clang-1200.0.32.29)]
None traces: []
Hello

% PYTHONPATH=$(pwd) python3.11 prog.py
3.11.0a5 (main, Feb  3 2022, 19:11:58) [Clang 12.0.0 (clang-1200.0.32.29)]
None traces: [('<module>', '/usr/local/pyenv/pyenv/versions/3.11.0a5/lib/python3.11/encodings/__init__.py'), ('<module>', '<frozen codecs>'), ('<module>', '/usr/local/pyenv/pyenv/versions/3.11.0a5/lib/python3.11/encodings/aliases.py'), ('<module>', '/usr/local/pyenv/pyenv/versions/3.11.0a5/lib/python3.11/encodings/utf_8.py'), ('<module>', '<frozen io>'), ('<module>', '<frozen abc>'), ('<module>', '<frozen site>'), ('<module>', '<frozen os>'), ('<module>', '<frozen stat>'), ('<module>', '<frozen _collections_abc>'), ('<module>', '<frozen posixpath>'), ('<module>', '<frozen genericpath>'), ('<module>', '<frozen _sitebuiltins>'), ('<module>', '<string>'), ('<module>', '/System/Volumes/Data/root/src/bugs/fullcov/prog.py')]
Hello

----------
components: Interpreter Core
keywords: 3.11regression
messages: 414438
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Early tracing has lineno=None for modules
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar  3 09:48:34 2022
From: report at bugs.python.org (Alexei Komarov)
Date: Thu, 03 Mar 2022 14:48:34 +0000
Subject: [New-bugs-announce] [issue46912] Full gc collection blocked from
 collecting after some amount of objects in oldest gen
Message-ID: <1646318914.17.0.951983551273.issue46912@roundup.psfhosted.org>


New submission from Alexei Komarov <al3x3i.k at gmail.com>:

Hi!

Maybe it is just my misunderstanding of the mechanism, so please excuse me if it is so. Looking at the GC module code, I think that once there are X objects in the oldest gen, a full collection blocked due to the condition https://github.com/python/cpython/blob/3.10/Modules/gcmodule.c#L1465-L1467 being always True.

So, if youngest gen is collected each 700 objects, the middle gen will have maximum 7000 objects. Full collection will be triggered each ~70K objects. X/4 = 70000 ===> X=280000. If oldest gen has >280K objects in it, the condition for full collection (long_lived_pending < gcstate->long_lived_total / 4) is always true since to my understanding, long_lived_pending is 70K at most, and got zeroed each full collection (https://github.com/python/cpython/blob/3.10/Modules/gcmodule.c#L1253).

----------
components: Extension Modules
messages: 414444
nosy: al3x3i.k
priority: normal
severity: normal
status: open
title: Full gc collection blocked from collecting after some amount of objects in oldest gen
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar  3 11:19:36 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Mar 2022 16:19:36 +0000
Subject: [New-bugs-announce] [issue46913] UBSAN: test_ctypes,
 test_faulthandler and test_hashlib are failing
Message-ID: <1646324376.37.0.339343384367.issue46913@roundup.psfhosted.org>


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

I recently changed how tests are skipped in ASAN, MSAN and UBSAN CIs (buildbot workers and GitHub Action jobs):

* bpo-46633
* https://github.com/python/buildmaster-config/commit/0fd1e3e49e4b688d5767501484cccea5fa35d3fc

3 tests are now failing on "AMD64 Arch Linux Usan 3.x":

* test_ctypes
* test_faulthandler
* test_hashlib

First failed build:
https://buildbot.python.org/all/#/builders/719/builds/632

----------
components: Tests
messages: 414455
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar  3 15:07:57 2022
From: report at bugs.python.org (Philip Bloom)
Date: Thu, 03 Mar 2022 20:07:57 +0000
Subject: [New-bugs-announce] [issue46914] On Osx Monterey(12.x),
 Logging.handlers.SysLogHandler does not work
Message-ID: <1646338077.17.0.950796200691.issue46914@roundup.psfhosted.org>


New submission from Philip Bloom <pbloom at mz.com>:

Hello, don't file these often so apologies for any mistakes, trying to be good python citizen here.

Checked this on the python-list first, and others reported it as reproducible.

The issue is:
On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work.  It won't throw any error but the ASL/Console.App does not see any messages from it.  On OSX Big Sur (11.x) this works just fine with the exact same code.

I think I've cut this into a small example proof that can be run to demonstrate the issue.  If this is run and any of the substrings are searched for in Console.App when it is checking events, only the QQQ message from SysLog will show up.

Gonna work around it likely on our end, but hope this helps it get fixed for a future version.

---

import logging
from logging.handlers import SysLogHandler

root_logger = logging.getLogger()
root_logger.setLevel(logging.DEBUG)
basic_datefmt = '%m/%d/%Y %I:%M:%S %p'

syslog_format = logging.Formatter(fmt='SetupCDNGUI: %(message)s', datefmt=basic_datefmt)

sys_handler = SysLogHandler(address='/var/run/syslog')
#sys_handler.encodePriority(SysLogHandler.LOG_USER, SysLogHandler.LOG_ALERT)
# Tried with the above, but didn't make a difference.  Neither did not defining the address and letting it go to local host.
sys_handler.setFormatter(syslog_format)
root_logger.addHandler(sys_handler)


# None of these will show up.
logging.critical("CCC This is a test critical")
logging.error("EEE This is a test error")
logging.info("III Still a test")


# Comparatively this sends a message received just fine
import syslog

syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER)
syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log')

----------
components: macOS
messages: 414464
nosy: ned.deily, pbloom, ronaldoussoren
priority: normal
severity: normal
status: open
title: On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar  3 16:15:25 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 03 Mar 2022 21:15:25 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue46915=5D_Build_with_Py=5FL?=
 =?utf-8?q?IMITED=5FAPI_fails_unknown_type_name_=E2=80=98PyModuleDef=5FSlo?=
 =?utf-8?b?dOKAmQ==?=
Message-ID: <1646342125.75.0.0439874391605.issue46915@roundup.psfhosted.org>


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

Extension modules with bare "#define Py_LIMITED_API" without version fail to build with error:

   moduleobject.h:82:3: error: unknown type name ?PyModuleDef_Slot?

The issue was introduced in PR GH-31528 and bpo-45459. The type PyModuleDef_Slot is only defined when Py_LIMITED_API is set to Python 3.5.0 or higher.

----------
assignee: christian.heimes
components: Build, Interpreter Core
keywords: 3.11regression
messages: 414473
nosy: christian.heimes, pablogsal, vstinner
priority: release blocker
severity: normal
status: open
title: Build with Py_LIMITED_API fails unknown type name ?PyModuleDef_Slot?
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar  3 17:17:38 2022
From: report at bugs.python.org (Vincent FUNG)
Date: Thu, 03 Mar 2022 22:17:38 +0000
Subject: [New-bugs-announce] [issue46916] There is a problem with escape
 characters in the path passed in by pathlib.Path.mkdir()
Message-ID: <1646345858.65.0.182436271854.issue46916@roundup.psfhosted.org>


New submission from Vincent FUNG <vincent201399 at gmail.com>:

This problem occurs when the directory starts with 't', but works with os.makedirs(e) or macOS.

>>> e = Path(r'F:\ceven\test2')
>>> e.mkdir()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\Python310\lib\pathlib.py", line 1173, in mkdir
    self._accessor.mkdir(self, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'F:\\ceven\\test2'
>>> os.makedirs(e)

----------
components: Windows
messages: 414483
nosy: paul.moore, steve.dower, tim.golden, vincent.fung, zach.ware
priority: normal
severity: normal
status: open
title: There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar  3 17:39:43 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Mar 2022 22:39:43 +0000
Subject: [New-bugs-announce] [issue46917] Require IEEE 754 floating point to
 build Python 3.11
Message-ID: <1646347183.1.0.816750157745.issue46917@roundup.psfhosted.org>


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

See "[Python-Dev] Should we require IEEE 754 floating-point for CPython?" thread:
https://mail.python.org/archives/list/python-dev at python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/

I propose to require IEEE 754 floating-point to build Python 3.11. I propose the following build:

* Mention the new build requirement in What's New in Python 3.11.
* Modify configure script to make it fail if the IEEE 754 support is missing.
* Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.
* Remove @requires_IEEE_754 decorator of test.support and tests.
* Remove "unknown_format" code path of pack/unpack functions like _PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).


The _PY_SHORT_FLOAT_REPR==0 code path is kept. For now, platforms with float larger than 64-bit but without HAVE_PY_SET_53BIT_PRECISION are still supported (but don't get "short float repr"). See GH-31592 for details.


I prepared this requirement with these two changes:

commit 1b2611eb0283055835e5df632a7a735db8c894b8
Author: Victor Stinner <vstinner at python.org>
Date:   Fri Feb 25 01:32:57 2022 +0100

    bpo-46656: Remove Py_NO_NAN macro (GH-31160)
    
    Building Python now requires support for floating point Not-a-Number
    (NaN): remove the Py_NO_NAN macro.

commit 5ab745fc51e159ead28b523414e52f0bcc1ef353
Author: Victor Stinner <vstinner at python.org>
Date:   Sat Feb 26 00:53:27 2022 +0100

    bpo-46852: Remove the float.__set_format__() method (GH-31585)
    
    Remove the undocumented private float.__set_format__() method,
    previously known as float.__set_format__() in Python 3.7. Its
    docstring said: "You probably don't want to use this function. It
    exists mainly to be used in Python's test suite."


By the way, building Python 3.11 now requires a C11 compiler.

----------
components: Build
messages: 414485
nosy: vstinner
priority: normal
severity: normal
status: open
title: Require IEEE 754 floating point to build Python 3.11
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar  4 04:31:55 2022
From: report at bugs.python.org (zjmxq)
Date: Fri, 04 Mar 2022 09:31:55 +0000
Subject: [New-bugs-announce] [issue46918] The vulnerability is included in
 /lib/python3.9/ensurepip after python 3.9.2 is installed.
Message-ID: <1646386315.18.0.392218219699.issue46918@roundup.psfhosted.org>


New submission from zjmxq <zjmxq180 at 163.com>:

Vulnerability CVE-2021-29921,CVE-2020-14422, CVE-2021-3572, CVE-2021-33503 Vulnerability Found in python 3.9.2 /lib/python3.9/ensurepip

----------
components: Library (Lib)
messages: 414511
nosy: zjmxq
priority: normal
severity: normal
status: open
title: The vulnerability is included in /lib/python3.9/ensurepip after python 3.9.2 is installed.
type: security
versions: Python 3.9

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

From report at bugs.python.org  Fri Mar  4 04:34:32 2022
From: report at bugs.python.org (zjmxq)
Date: Fri, 04 Mar 2022 09:34:32 +0000
Subject: [New-bugs-announce] [issue46919] After Python 3.9.2 is installed,
 the CVE-2019-12900 and CVE-2016-3189 vulnerabilities exist in
 Python39/DLLs/_bz2.pyd.
Message-ID: <1646386472.07.0.567385422064.issue46919@roundup.psfhosted.org>


Change by zjmxq <zjmxq180 at 163.com>:


----------
components: Library (Lib)
nosy: zjmxq
priority: normal
severity: normal
status: open
title: After Python 3.9.2 is installed, the CVE-2019-12900 and CVE-2016-3189 vulnerabilities exist in Python39/DLLs/_bz2.pyd.
type: security
versions: Python 3.9

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

From report at bugs.python.org  Fri Mar  4 07:13:16 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Fri, 04 Mar 2022 12:13:16 +0000
Subject: [New-bugs-announce] [issue46920] Remove code made dead long ago
 with #if 0
Message-ID: <1646395996.16.0.71823057586.issue46920@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

`git grep "#if 0"` gives the following occurences of dead code (analyzed with `git blame`, removed by a linked pull request):

- added on 27 Apr 2020 by 2b74c83: Parser/pegen.h:9, Parser/pegen.h:15. Since these constants aren't mentioned anywhere else, I think it's some initial experiment now abandoned.

- added on 23 Apr 2020 by c5fc156: Parser/pegen.c:40. `token_name` is mentioned nowhere in the CPython codebase too.

- added on 20 Nov 2014 by d600951: Python/pylifecycle.c:1843 with the following note:

  > XXX This is disabled because it caused too many problems.  If a __del__ or weakref callback triggers here, Python code has a hard time running, because even the sys module has been cleared out (sys.stdout is gone, sys.excepthook is gone, etc).  One symptom is a sequence of information-free messages coming from threads (if a __del__ or callback is invoked, other threads can execute too, and any exception they encounter triggers a comedy of errors as subsystem after subsystem fails to find what it *expects* to find in sys to help report the exception and consequent unexpected failures).  I've also seen segfaults then, after adding print statements to the Python code getting called.

  So the call is faulty for seven years with no progress.

- added on 26 Oct 2013 by 8444ebb: Modules/sre_lib.h336. The Secret Labs' Regular Expression Engine was vendored nine years ago so `not used in this release` is permanent and can be removed.

- added on 25 Aug 2012 by 2543756: Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:155

- added on 21 Mar 2012 by 1919b7e: Modules/_decimal/libmpdec/sixstep.c:120, Modules/_decimal/libmpdec/sixstep.c:157, Modules/_decimal/libmpdec/fourstep.c:189, Modules/_decimal/libmpdec/fourstep.c:220

- added on 28 Sep 2011 by d63a3b8: Python/formatter_unicode.c:140. `DEBUG_PRINT_FORMAT_SPEC` is used nowhere, plus putting a debugger breakpoint onto an interesting `InternalFormatSpec` is more convenient.

- added on 5 Mar 2008 by 7864476: Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c:40

- added on 27 Aug 2007 by e226b55: Objects/unicodeobject.c:13660, Objects/unicodeobject.c:14253. `_decimal2ascii` is mentioned nowhere else in the CPython codebase.

- added on 11 Aug 2006 by 0e3f591: Python/compile.c:7873. Neither `dump_instr` nor `dump_basicblock` are used.

- added on 7 Dec 2005 by 8c8836b: Modules/_elementtree.c:39. In addition, `ALLOC()` and `RELEASE()` are removed as unconditional no-ops.

- added on 4 Aug 2002 by 00f1e3f: Parser/tokenizer.c:285. "/* Disable support for UTF-16 BOMs until a decision is made whether this needs to be supported */" - I have every reason to believe that the decision was Never Ever.

- added on 23 Mar 2002 by c24ea08: Python/ceval.c:7065-L7070. The "/* future keyword */" is quite overdue already.

- added on 23 Jun 2001 by 01dfdb3: Modules/getaddrinfo.c:41, Modules/getnameinfo.c:37

- added on 14 Jul 1998 by 43ff868: Modules/_tkinter.c:3443

----------
components: Extension Modules, Interpreter Core, Unicode, macOS
messages: 414519
nosy: arhadthedev, ezio.melotti, ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
status: open
title: Remove code made dead long ago with #if 0
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar  4 11:42:42 2022
From: report at bugs.python.org (Ken Jin)
Date: Fri, 04 Mar 2022 16:42:42 +0000
Subject: [New-bugs-announce] [issue46921] Vectorcall support for super()
Message-ID: <1646412162.98.0.58372523798.issue46921@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

This is related to bpo-46564. The changes are less ambitious but should produce a nice speedup.

----------
messages: 414535
nosy: kj
priority: normal
severity: normal
status: open
title: Vectorcall support for super()
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar  4 11:43:29 2022
From: report at bugs.python.org (progval)
Date: Fri, 04 Mar 2022 16:43:29 +0000
Subject: [New-bugs-announce] [issue46922] tarfile.TarFile.next() crashes on
 empty tar files
Message-ID: <1646412209.92.0.374671819607.issue46922@roundup.psfhosted.org>


New submission from progval <progval+bugs.python.org at progval.net>:

Hi,

I found two related bugs when calling tarfile.TarFile.next() on an empty tar file, both when trying to seek when it should not:

import io
import tarfile

# Create a tarball with no member:
fd = io.BytesIO()
with tarfile.open(fileobj=fd, mode="w") as tf:
    pass

# read in stream mode:
fd.seek(0)
with tarfile.open(fileobj=fd, mode="r|") as tf:
    print(tf.next())   # tarfile.StreamError: seeking backwards is not allowed

# read in normal mode:
fd.seek(0)
with tarfile.open(fileobj=fd, mode="r") as tf:
    print(tf.next())  # ValueError: negative seek value -1

----------
components: Library (Lib)
messages: 414536
nosy: progval
priority: normal
severity: normal
status: open
title: tarfile.TarFile.next() crashes on empty tar files
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri Mar  4 11:54:19 2022
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 04 Mar 2022 16:54:19 +0000
Subject: [New-bugs-announce] [issue46923] Implement stack overflow
 protection for supported platforms
Message-ID: <1646412859.37.0.291420290315.issue46923@roundup.psfhosted.org>


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

https://github.com/python/steering-council/issues/102 (definitely not PEP 651 ;))

We should implement efficient stack checks on those platforms that allow us to introspect stack extents.
Windows and posix systems allow us to do this.

C allows addresses of stack variables to be taken. This means that C stacks cannot be moved.
In theory they might be discontinuous, although I suspect that they are always contiguous.

My plan is to maintain a per-thread "safe region" of 32or 64k. We can check if the current stack pointer (or near enough) is in that region cheaply.
If we are not in that region, we can ask the O/S for a stack limit to determine a new "safe region". If we cannot find a safe region, then we raise a MemoryError.

Personally I'd prefer a new exception `StackOverflow` to `MemoryError` but, thanks to stackoverflow.com, it is now impossible for new programmers to do a web search to determine what a "stack overflow" is.
So, I guess MemoryError will have to do.

----------
assignee: Mark.Shannon
messages: 414538
nosy: Mark.Shannon, gregory.p.smith
priority: normal
severity: normal
status: open
title: Implement stack overflow protection for supported platforms

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

From report at bugs.python.org  Fri Mar  4 14:17:30 2022
From: report at bugs.python.org (AmericanEnglish)
Date: Fri, 04 Mar 2022 19:17:30 +0000
Subject: [New-bugs-announce] [issue46924] make install hangs when installing
 zoneinfo/_zoneinfo.py
Message-ID: <1646421450.64.0.938148435376.issue46924@roundup.psfhosted.org>


New submission from AmericanEnglish <barajasc at umbc.edu>:

I am currently trying to compile Python 3.10.2 from source. Everything seems to compile fine when doing a configure then a make. When I do make install though the install process hangs when compiling zoneinfo/_zoneinfo.py . Currently there are 6 python processes running when I view top. I have left this for several hours and the status is unchanged.

Here is the configure command I used:

export CXX=icpx
export CC=icx
# icx uses LLVM, so this is required for ctypes...?
export CFLAGS="-no-integrated-as"
# icx uses a clang frontend so these should be used as suggested by:
# https://devguide.python.org/setup/
export CFLAGS="$CFLAGS -Wno-unused-value -Wno-empty-body -Qunused-arguments"

cd $BUILD
../../302/configure \
    --prefix $PREFIX \
    --enable-profiling \
    --enable-optimizations \
    --with-ensurepip=install > configureOutput.txt


everything runs fine. When I CTRL+C to kill the make install it drops an error:
KeyboardInterrupt
  File "/installation/lib/python3.10/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/installation/lib/python3.10/multiprocessing/queues.py", line 102, in get
    with self._rlock:
  File "/installation/lib/python3.10/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in _bootstrap
[interrupted]
make: [libinstall] Error 1 (ignored)


Any advice would be greatly appreciated. I have tried Googling the problem and searching StackOverflow and found no solutions that work.

I will say that this happens with AND without optimizations enabled.

----------
components: Installation
messages: 414548
nosy: AmericanEnglish
priority: normal
severity: normal
status: open
title: make install hangs when installing zoneinfo/_zoneinfo.py
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Fri Mar  4 18:25:53 2022
From: report at bugs.python.org (Malthe Borch)
Date: Fri, 04 Mar 2022 23:25:53 +0000
Subject: [New-bugs-announce] [issue46925] Replace key if not identical to
 old key in dict
Message-ID: <1646436353.66.0.753916572572.issue46925@roundup.psfhosted.org>


New submission from Malthe Borch <mborch at gmail.com>:

When a key that is equal to an existing key (but not the same object identity) is used to set a new value, the key itself is not replaced.

This manifests perhaps most clearly in `weakref.WeakKeyDictionary` where keys can mysteriously disappear.

Consider two equal keys, k1 and k2:

d = WeakKeyDictionary()
d[k1] = 1
d[k2] = 2
del k1

We would expect the dictionary to have a single entry k2 => 2. But in fact it is empty now.

----------
components: Library (Lib)
messages: 414554
nosy: malthe
priority: normal
pull_requests: 29811
severity: normal
status: open
title: Replace key if not identical to old key in dict
type: behavior

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

From report at bugs.python.org  Fri Mar  4 19:01:39 2022
From: report at bugs.python.org (Charlie Yan)
Date: Sat, 05 Mar 2022 00:01:39 +0000
Subject: [New-bugs-announce] [issue46926] runpy.run_path didn't set
 __package__ as describe in doc
Message-ID: <1646438499.21.0.962171023528.issue46926@roundup.psfhosted.org>


New submission from Charlie Yan <yanhao.charles at gmail.com>:

As described in the doc: https://docs.python.org/3.8/library/runpy.html#runpy.run_path

> If the supplied path directly references a script file (whether as source or as precompiled byte code), then __file__ will be set to the supplied path, and __spec__, __cached__, __loader__ and __package__ will all be set to None.

But:
```
$ cat a.py
print(f'{__name__ = }')
print(f'{__package__ = }')

$ cat b.py
import runpy
runpy.run_path('a.py')

$ python3 b.py
__name__ = '<run_path>'
__package__ = ''
```

`__package__` is not set to None as in the doc.

----------
messages: 414555
nosy: yanhao.charles
priority: normal
severity: normal
status: open
title: runpy.run_path didn't set __package__ as describe in doc
versions: Python 3.8

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

From report at bugs.python.org  Sat Mar  5 05:18:42 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Mar 2022 10:18:42 +0000
Subject: [New-bugs-announce] [issue46927] Improve error message for
 subscripting non-generic types
Message-ID: <1646475522.66.0.0981831027946.issue46927@roundup.psfhosted.org>


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

Currently, if you try to subscript a non-generic type you will get an error:

>>> int[str]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'type' object is not subscriptable

Yes, 'type' objects are usually not subscriptable, but list[str] works, and it is not clear from the error message for what type it is failed.

The following PR changes an error message:

>>> int[str]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'int' is not subscriptable

----------
components: Interpreter Core
messages: 414573
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve error message for subscripting non-generic types
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar  5 05:41:07 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 05 Mar 2022 10:41:07 +0000
Subject: [New-bugs-announce] [issue46928] type.__qualname__ ignores module
 name in tp_name for static types
Message-ID: <1646476867.36.0.734336530708.issue46928@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

In a static type when the "tp_name" is set to a fully qualified name (such as "my.package.TypeName") the "__qualname__" returns the unqualified name ("TypeName") instead of the fully qualified name.

The type's ``__name__`` and ``__module__`` have the expected value.

This is IMHO a bug in the implementation of type_qualname in Objects/typeobject.c.

Note that setting ``__qualname__`` in the types's ``__dict__`` doesn't work, that value is ignored.

----------
components: Interpreter Core
messages: 414574
nosy: ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: type.__qualname__ ignores module name in tp_name for static types
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Mar  5 09:33:30 2022
From: report at bugs.python.org (ZhengYu, Xu)
Date: Sat, 05 Mar 2022 14:33:30 +0000
Subject: [New-bugs-announce] [issue46929] __rrshift__ for same class obj
 will raise TypeError
Message-ID: <1646490810.86.0.339104113044.issue46929@roundup.psfhosted.org>


New submission from ZhengYu, Xu <zen-xu at outlook.com>:

```
class C:
    def __rrshift__(self, v):
        return 1

C() >> C()   # raise TypeError: unsupported operand types(s) for >>: 'C' and 'C'
```

----------
messages: 414578
nosy: zen-xu
priority: normal
severity: normal
status: open
title: __rrshift__ for same class obj will  raise TypeError
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Mar  5 10:33:42 2022
From: report at bugs.python.org (Fabian Zills)
Date: Sat, 05 Mar 2022 15:33:42 +0000
Subject: [New-bugs-announce] [issue46930] Iterating over cls.__dict__ in
 classmethod causes RuntimeError when printing __annotations__
Message-ID: <1646494422.15.0.024229074835.issue46930@roundup.psfhosted.org>


New submission from Fabian Zills <fabian.zills at web.de>:

When iterating over __dict__ inside a classmethod, accessing __annotations causses RuntimeError: dictionary changed size during iteration.
This only seems to affect Python 3.10.x on a Ubuntu system.

The following can be used to reproduce this issue:

class ExampleCls:
    @classmethod
    def iter_cls(cls):
        for name, val in cls.__dict__.items():
            print(cls.__annotations__)


This can be fixed for this Example by calling  _ = cls.__annotations__ before iterating over the __dict__

----------
messages: 414582
nosy: PythonF
priority: normal
severity: normal
status: open
title: Iterating over cls.__dict__ in classmethod causes RuntimeError when printing __annotations__
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Sat Mar  5 12:37:33 2022
From: report at bugs.python.org (Vertu Joe)
Date: Sat, 05 Mar 2022 17:37:33 +0000
Subject: [New-bugs-announce] [issue46931] zipfile library will raise
 uncaught oserror when reading length incorrect zip file
Message-ID: <1646501853.93.0.304321203932.issue46931@roundup.psfhosted.org>


New submission from Vertu Joe <ultimalium at gmail.com>:

I intentionally made some corrupted zip archive files for testing.
If some contents were removed from the archive instead of changing the bits. when trying to read such files, the zipfile will raise an uncaught  OSError, instead of a badzipfile error as expected.

os is windows 10 x64 not sure if this also happens on the UNIX system or it's intended to be happen.

code:

import zipfile
with zipfile.ZipFile(r'damaged.zip') as dmg:
    dmg.testzip()

result:
OSError
[Errno 22] Invalid argument
  File "test.py", line 20, in <module>
    file = dmg.testzip()

----------
components: Library (Lib)
files: damaged.zip
messages: 414590
nosy: ultimalium
priority: normal
severity: normal
status: open
title: zipfile library will raise uncaught oserror when reading length incorrect zip file
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50658/damaged.zip

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

From report at bugs.python.org  Sat Mar  5 13:03:18 2022
From: report at bugs.python.org (sping)
Date: Sat, 05 Mar 2022 18:03:18 +0000
Subject: [New-bugs-announce] [issue46932] Please update bundled libexpat to
 2.4.7 with an important fix
Message-ID: <1646503398.23.0.962856817439.issue46932@roundup.psfhosted.org>


New submission from sping <sebastian at pipping.org>:

Hi!

I believe the fix documented at https://github.com/libexpat/libexpat/blob/27d5b8ba1771f916d9cfea2aac6bdac72071dc66/expat/Changes#L7-L11 is important to users of CPython.  Please update bundled libexpat to 2.4.7.  Thank you!

Best, Sebastian

----------
components: XML
messages: 414591
nosy: sping
priority: normal
severity: normal
status: open
title: Please update bundled libexpat to 2.4.7 with an important fix
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Mar  5 15:50:25 2022
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 05 Mar 2022 20:50:25 +0000
Subject: [New-bugs-announce] [issue46933] Make pwd module optional for
 wasm32-emscripten and wasi
Message-ID: <1646513425.19.0.684732114682.issue46933@roundup.psfhosted.org>


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

WebAssembly platforms like wasm32-emscripten and wasm32-wasi don't have a typical user and group database.

WASI platform does not provide necessary API functions at all. Emscripten provides dummy stubs. On Emscripten the pwd module compiles, but is non-functional:

Python 3.11.0a4+ (heads/main-dirty:b1a3446, Jan 25 2022, 10:19:07) [Clang 14.0.0 (https://github.com/llvm/llvm-project f142c45f1e494f8dbdcc1bcf1412 on emscripten
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd, os
>>> os.getuid()
0
>>> pwd.getpwall()
[]
>>> pwd.getpwuid(os.getuid())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getpwuid(): uid not found: 0'

I propose to make the pwd optional and catch import error in few places where the pwd module is used to look up user home directory.

----------
assignee: christian.heimes
components: Library (Lib)
messages: 414595
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Make pwd module optional for wasm32-emscripten and wasi
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar  5 17:19:15 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 05 Mar 2022 22:19:15 +0000
Subject: [New-bugs-announce] [issue46934] A started multiprocessing.Process
 instance cannot be serialised
Message-ID: <1646518755.67.0.655660314231.issue46934@roundup.psfhosted.org>


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

The Python program:

```
import multiprocessing
import time


class Application:

    def __init__(self):
        self._event = multiprocessing.Event()
        self._processes = [
            multiprocessing.Process(target=self._worker)
            for _ in range(multiprocessing.cpu_count())]

    def _worker(self):
        while not self._event.is_set():
            print(multiprocessing.current_process().name)
            time.sleep(1)

    def start(self):
        for process in self._processes:
            print('starting')
            process.start()

    def stop(self):
        self._event.set()
        for process in self._processes:
            process.join()


if __name__ == '__main__':
    application = Application()
    application.start()
    time.sleep(3)
    application.stop()
```

Its output:

```none
starting
starting
Traceback (most recent call last):
  File "/Users/maggyero/Desktop/application.py", line 31, in <module>
    application.start()
  File "/Users/maggyero/Desktop/application.py", line 21, in start
    process.start()
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py", line 284, in _Popen
    return Popen(process_obj)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
TypeError: cannot pickle 'weakref' object
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 116, in spawn_main
    exitcode = _main(fd, parent_sentinel)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/spawn.py", line 126, in _main
    self = reduction.pickle.load(from_parent)
  File "/usr/local/Cellar/python at 3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/synchronize.py", line 110, in __setstate__
    self._semlock = _multiprocessing.SemLock._rebuild(*state)
FileNotFoundError: [Errno 2] No such file or directory
```

In the function `Application.__init__`, each call `multiprocessing.Process(target=self._worker)` initializes a `multiprocessing.Process` instance with the instance method `self._worker` as its `target` argument. `self._worker` is bound to `self` which has the instance attribute `self._processes`.

In the function `Application.start`, each call `process.start()` serialises the `target` argument and therefore `self._processes`. `self._processes` is a list of `multiprocessing.Process` instances, initially not started yet. The first call `process.start()` starts the first `multiprocessing.Process` instance in that list without issue, but the second call `process.start()` fails.

So a started `multiprocessing.Process` instance cannot be serialised.

The root of the problem is that the `start` method of a `multiprocessing.Process` instance sets its `_popen` instance attribute to a `multiprocessing.popen_*.Popen` instance. The initialization of that instance performs these two steps (among others):

1. For a `multiprocessing.popen_spawn_posix.Popen` instance, a `multiprocessing.popen_spawn_win32.Popen` instance, or a `multiprocessing.popen_forkserver.Popen` instance but not a `multiprocessing.popen_fork.Popen` instance (i.e. for the start method `'spawn'` or the start method `'forkserver'` but not the start method `'fork'`), it [serialises](https://github.com/python/cpython/blob/v3.10.2/Lib/multiprocessing/popen_spawn_posix.py#L47) the `multiprocessing.Process` instance for writing it to the end of the pipe used by the parent process to communicate with the child process so that the child process can execute the `run` method of the `multiprocessing.Process` instance.

2. It [sets](https://github.com/python/cpython/blob/v3.10.2/Lib/multiprocessing/popen_spawn_posix.py#L68) its `finalizer` instance attribute to a `multiprocessing.util.Finalize` instance which itself sets its `_weakref` instance attribute to a `weakref.ref` instance for closing at interpreter exit the ends of the pipes used by the parent process to communicate with the child process. In other words, it makes the `multiprocessing.Process` instance hold a weak reference.

Thus if a `multiprocessing.Process` instance holds a reference to a started `multiprocessing.Process` instance then it holds a weak reference (point 2), so starting it will fail since it will serialise (point 1) the weak reference and weak references are not serialisable:

```
import multiprocessing

if __name__ == '__main__':
    multiprocessing.set_start_method('spawn')  # or 'forkserver' but not 'fork'
    process_a = multiprocessing.Process()
    process_b = multiprocessing.Process()
    process_b.foo = process_a
    process_a.start()  # creates process_a._popen.finalizer._weakref
    process_b.start()  # TypeError: cannot pickle 'weakref' object
```

A minimal Python program showing the serialisation issue:

```
import pickle
import weakref

pickle.dumps(weakref.ref(int))  # TypeError: cannot pickle 'weakref' object
```

----------
components: Library (Lib)
messages: 414597
nosy: maggyero
priority: normal
severity: normal
status: open
title: A started multiprocessing.Process instance cannot be serialised
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar  5 17:26:32 2022
From: report at bugs.python.org (Max Bachmann)
Date: Sat, 05 Mar 2022 22:26:32 +0000
Subject: [New-bugs-announce] [issue46935] import of submodule polutes global
 namespace
Message-ID: <1646519192.38.0.0729050305481.issue46935@roundup.psfhosted.org>


New submission from Max Bachmann <kontakt at maxbachmann.de>:

In my environment I installed the following two libraries:
```
pip install rapidfuzz
pip install python-Levenshtein
```
Those two libraries have the following structures:
rapidfuzz
|-distance
  |- __init__.py (from . import Levenshtein)
  |- Levenshtein.*.so
|-__init__.py (from rapidfuzz import distance)


Levenshtein
|-__init__.py

When importing Levenshtein first everything behaves as expected:
```
>>> import Levenshtein
>>> Levenshtein.
Levenshtein.apply_edit(       Levenshtein.jaro_winkler(     Levenshtein.ratio(
Levenshtein.distance(         Levenshtein.matching_blocks(  Levenshtein.seqratio(
Levenshtein.editops(          Levenshtein.median(           Levenshtein.setmedian(
Levenshtein.hamming(          Levenshtein.median_improve(   Levenshtein.setratio(
Levenshtein.inverse(          Levenshtein.opcodes(          Levenshtein.subtract_edit(
Levenshtein.jaro(             Levenshtein.quickmedian(   
>>> import rapidfuzz
>>> Levenshtein.
Levenshtein.apply_edit(       Levenshtein.jaro_winkler(     Levenshtein.ratio(
Levenshtein.distance(         Levenshtein.matching_blocks(  Levenshtein.seqratio(
Levenshtein.editops(          Levenshtein.median(           Levenshtein.setmedian(
Levenshtein.hamming(          Levenshtein.median_improve(   Levenshtein.setratio(
Levenshtein.inverse(          Levenshtein.opcodes(          Levenshtein.subtract_edit(
Levenshtein.jaro(             Levenshtein.quickmedian( 
```

However when importing rapidfuzz first it import `rapidfuzz.distance.Levenshtein` when running `import Levenshtein`
```
>>> import rapidfuzz
>>> Levenshtein
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'Levenshtein' is not defined
>>> import Levenshtein
>>> Levenshtein.
Levenshtein.array(                  Levenshtein.normalized_distance(    Levenshtein.similarity(
Levenshtein.distance(               Levenshtein.normalized_similarity(  
Levenshtein.editops(                Levenshtein.opcodes( 
```

My expectation was that in both cases `import Levenshtein` should import the `Levenshtein` module. I could reproduce this behavior on all Python versions I had available (Python3.8 - Python3.10) on Ubuntu and Fedora.

----------
components: Interpreter Core
messages: 414599
nosy: maxbachmann
priority: normal
severity: normal
status: open
title: import of submodule polutes global namespace
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Mar  6 03:39:25 2022
From: report at bugs.python.org (Luca)
Date: Sun, 06 Mar 2022 08:39:25 +0000
Subject: [New-bugs-announce] [issue46936] Fix grammar_grapher with the new
 forced directive
Message-ID: <1646555965.39.0.197872234422.issue46936@roundup.psfhosted.org>


New submission from Luca <luca at chiodini.org>:

The grammar_grapher.py utility has not been updated after the introduction  of the new "forced" directive ('&&') in the grammar (see https://github.com/python/cpython/pull/24292) and fails to visualize the current Python grammar.

----------
components: Parser
messages: 414608
nosy: lucach, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Fix grammar_grapher with the new forced directive

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

From report at bugs.python.org  Sun Mar  6 03:50:50 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sun, 06 Mar 2022 08:50:50 +0000
Subject: [New-bugs-announce] [issue46937] convert remaining functions to AC
 in _weakref
Message-ID: <1646556650.89.0.985996387629.issue46937@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Convert remaining functions to AC in _weakref so that they use the FASTCALL calling convection.

----------
messages: 414609
nosy: kumaraditya303
priority: normal
severity: normal
status: open
title: convert remaining functions to AC in _weakref
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar  6 06:34:34 2022
From: report at bugs.python.org (Bar Harel)
Date: Sun, 06 Mar 2022 11:34:34 +0000
Subject: [New-bugs-announce] [issue46938] dataclass __post_init__ recursion
Message-ID: <1646566474.17.0.0323337902851.issue46938@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Not sure if a continuance of https://bugs.python.org/issue44365 or not, but the suggestion to call super().__init__() in __post__init__ will cause infinite recursion if the superclass also contains __post__init__:

>>> @d
... class A:
...  test: int
...  def __post_init__(self):
...    pass

>>> @d
... class B(A):
...  test2: int
...  def __post_init__(self):
...    super().__init__(test=1)

>>> B(test2=1, test=3) <-- infinite recursion.

This is caused by line 564 (https://github.com/python/cpython/blob/4716f70c8543d12d18c64677af650d479b99edac/Lib/dataclasses.py#L564) checking for post init on current class, and calling it on self (child class).

Not sure if the bug is in the documentation/suggestion, or if it's a bug in the implementation, in which case we need to call the current class's __post_init__.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 414613
nosy: bar.harel, docs at python
priority: normal
severity: normal
status: open
title: dataclass __post_init__ recursion
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Mar  6 08:49:31 2022
From: report at bugs.python.org (Ken Jin)
Date: Sun, 06 Mar 2022 13:49:31 +0000
Subject: [New-bugs-announce] [issue46939] Specialize calls for Python classes
Message-ID: <1646574571.32.0.472167982786.issue46939@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Please see https://github.com/faster-cpython/ideas/issues/267.

I hope I'm not stepping on anyone's toes here (sorry if I cause any duplicate work)!

----------
messages: 414618
nosy: Mark.Shannon, kj
priority: normal
severity: normal
status: open
title: Specialize calls for Python classes
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar  6 15:14:41 2022
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 06 Mar 2022 20:14:41 +0000
Subject: [New-bugs-announce] [issue46940] Suggestion messages don't properly
 work in nested getattr calls
Message-ID: <1646597681.21.0.64157062994.issue46940@roundup.psfhosted.org>


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

Consider this code:

class A:
    __slots__ = [
        "_color",
    ]

    color = None

    @property
    def color(self):
        return self._color


A().color


Executing this shows:

Traceback (most recent call last):
  File "/Users/pgalindo3/lel.py", line 21, in <module>
    A().color
  File "/Users/pgalindo3/lel.py", line 18, in color
    return self._color
AttributeError: 'A' object has no attribute '_color'. Did you mean: '_color'?

This is because the nested getattr call of "@property" overrides the metadata information in the exception object and it tries to produce an error message for the attribute "color" instead of "_color".

----------
assignee: pablogsal
messages: 414623
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Suggestion messages don't properly work in nested getattr calls
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun Mar  6 19:42:57 2022
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQodC70LDQsdC40YbQutC40Lk=?=)
Date: Mon, 07 Mar 2022 00:42:57 +0000
Subject: [New-bugs-announce] [issue46941] Bug or plug not removed (The
 operator "is")
Message-ID: <1646613777.85.0.744767351545.issue46941@roundup.psfhosted.org>


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

I understand it's a stub that hasn't been removed, so it's a message from the C language that Python runs on in principle.

----------
components: Interpreter Core
files: ???????????_2022-03-07_023751.png
messages: 414630
nosy: semina054
priority: normal
severity: normal
status: open
title: Bug or plug not removed (The operator "is")
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50659/???????????_2022-03-07_023751.png

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

From report at bugs.python.org  Mon Mar  7 03:50:35 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Mon, 07 Mar 2022 08:50:35 +0000
Subject: [New-bugs-announce] [issue46942] Convert Object/classobject.c to
 Argument Clinic
Message-ID: <1646643035.51.0.36036313662.issue46942@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

- Convert method.__reduce__, method.__new__, and instancemethod.__new__ to AC. It looks like nothing else can be converted in classobject.c.

  This is my first time working with AC so I could make some mistakes.

- Fix found mismatches in method.__new__ where docstring and implementation diverged:

  - on how to name arguments (function vs func, instance vs self) - `fuct` is a semi-abbreviation and `self` is a special argument of instance methods. No compatibility is harmed because these arguments were forced to be positional-only anyway with `if (!_PyArg_NoKeywords("method", kw)) return NULL;`.

  - on whether args are positional (the implementation called _PyArg_NoKeywords) or not (the documentation and Lib/idlelib/idle_test/test_calltip.py:80) - align with other assertions in `test_builtins()` that have reference docstrings with both `/` marker and a proper description.

Minor refactoring:

- Since PyMethod_Type and PyInstanceMethod_Type are modified anyway, transform their initialization to C99-style.

- Change a disabler for PyInstanceMethod_Type.tp_hash from comments to `#if 0`.

----------
components: Interpreter Core
messages: 414643
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Convert Object/classobject.c to Argument Clinic
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar  7 06:30:04 2022
From: report at bugs.python.org (SpaceOne)
Date: Mon, 07 Mar 2022 11:30:04 +0000
Subject: [New-bugs-announce] [issue46943] fix[imaplib]: call Exception with
 string instance
Message-ID: <1646652604.57.0.383929268002.issue46943@roundup.psfhosted.org>


New submission from SpaceOne <python at florianbest.de>:

imaplib raises an Exception with a bytes instance once (in login()) - all other places str instances are raised.

Adjust the behavior of login() similar to authenticate() where self.error is called with a str instance.

Especially for Python3 with strict bytes mode (-bb) this is helpful and prevents:

    Traceback (most recent call last):
      in "<stdin>"
        self.login(email, password)
      File "/usr/lib/python3.7/imaplib.py", line 598, in login
        raise self.error(dat[-1])
    imaplib.error: <exception str() failed>
    
    During handling of the above exception, another exception occurred:
    Traceback (most recent call last):
      in "<stdin>"
        str(exc)
    BytesWarning: str() on a bytes instance

----------
components: Library (Lib)
messages: 414657
nosy: spaceone
priority: normal
severity: normal
status: open
title: fix[imaplib]: call Exception with string instance
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/issue46943>
_______________________________________

From report at bugs.python.org  Mon Mar  7 06:56:36 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 07 Mar 2022 11:56:36 +0000
Subject: [New-bugs-announce] [issue46944] Use FASTCALL calling convention in
 generator.throw
Message-ID: <1646654196.99.0.903506705512.issue46944@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Use FASTCALL calling convention in generator.throw to avoid creating a temporary tuple to pass arguments to the function.

----------
components: Interpreter Core
messages: 414660
nosy: Mark.Shannon, kumaraditya303
priority: normal
pull_requests: 29839
severity: normal
status: open
title: Use FASTCALL calling convention in generator.throw
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar  7 08:19:26 2022
From: report at bugs.python.org (Vivian D)
Date: Mon, 07 Mar 2022 13:19:26 +0000
Subject: [New-bugs-announce] [issue46945] Quantifier and Expanded Regex
 Expression Gives Different Results
Message-ID: <1646659166.96.0.869118025108.issue46945@roundup.psfhosted.org>


New submission from Vivian D <vmd3.14 at gmail.com>:

Here are the steps that I went through to test my regular expressions in my command prompt (a file attachment shows this as well). I am using Windows 11, version 21H2:

>>> import re
>>> regex = r"(((\w)+\w*\3){2}|(\w)+(?=\w*\4)\w*(?!\4)(\w)\w*\5)\w*"
>>> testString = "Alabama and Mississippi are next to each other"
>>> re.findall(regex,testString,re.IGNORECASE)
[('Mississipp', 'ipp', 'p', '', '')]
>>> testString = "alabama and Mississippi are next to each other"
>>> re.findall(regex,testString,re.IGNORECASE)
[('Mississipp', 'ipp', 'p', '', '')]
>>> regex = r"((\w)+\w*\2(\w)+\w*\3|(\w)+(?=\w*\4)\w*(?!\4)(\w)\w*\5)\w*"
>>> re.findall(regex,testString,re.IGNORECASE)
[('alabama', 'a', 'a', '', ''), ('Mississipp', 's', 'p', '', '')]
>>> testString = "Alabama and Mississippi are next to each other"
>>> re.findall(regex,testString,re.IGNORECASE)
[('Alabama', 'A', 'a', '', ''), ('Mississipp', 's', 'p', '', '')]

I created a regular expression to match any words with two sets of the same vowel, including words with four of the same vowel, ignoring case. My first regular expression ?(((\w)+\w*\3){2}|(\w)+(?=\w*\4)\w*(?!\4)(\w)\w*\5)\w*" was able to match ?Mississippi? but unable to match ?Alabama? as it should have. To make sure that this error wasn?t somehow caused by a case sensitivity issue, I retested the regex with ?alabama? instead of ?Alabama?, but still I got no match on ?alabama?. Then I tried replacing the quantifier {2} with just expression that was supposed to be repeated. This gave me the regex: "((\w)+\w*\2(\w)+\w*\3|(\w)+(?=\w*\4)\w*(?!\4)(\w)\w*\5)\w*". For some reason, this was able to match on both ?alabama? and ?Alabama? now, as shown above, and continued to match on Mississippi like expected. However, this result seems to contradict my understand of regular expressions because all I did to get these different results was copy the expression that was supposed to be executed twice by the quantifier.

----------
components: Library (Lib)
files: ComandPrompt.pdf
messages: 414668
nosy: vmd3.14
priority: normal
severity: normal
status: open
title: Quantifier and Expanded Regex Expression Gives Different Results
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50661/ComandPrompt.pdf

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

From report at bugs.python.org  Mon Mar  7 09:12:29 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Mon, 07 Mar 2022 14:12:29 +0000
Subject: [New-bugs-announce] [issue46946] Port core types to Argument Clinic
Message-ID: <1646662349.93.0.569341400639.issue46946@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

This is done to:

- update docstrings to current standards enforced by AC
- get proper naming for arguments of impl-functions (for example, self instead of obj and instance)
- strip boilerplate reducing current 16k lines of code to something little more manageable
- get a proper excuse to collapse overbloated PyTypeObject initializers by throwing out zeroes with designated initialization thanks to C99&11 being promoted. For example, EncodingMapType in unicodeobject.c reduced from 43 lines to 8, five times less.

----------
components: Interpreter Core
messages: 414670
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Port core types to Argument Clinic
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar  7 10:20:26 2022
From: report at bugs.python.org (Joe Cool)
Date: Mon, 07 Mar 2022 15:20:26 +0000
Subject: [New-bugs-announce] [issue46947] unicodedata.name gives ValueError
 for control characters
Message-ID: <1646666426.33.0.722967640681.issue46947@roundup.psfhosted.org>


New submission from Joe Cool <snoopyjc at gmail.com>:

unicodedata.name gives ValueError for control characters, for example:

>>> unicodedata.name('\x00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: no such name
>>> unicodedata.name('\t')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: no such name


Where unicodedata.lookup clearly knows the names for these characters:
>>> unicodedata.lookup('NULL')
'\x00'
>>> unicodedata.lookup('TAB')
'\t'

----------
components: Library (Lib)
messages: 414672
nosy: snoopyjc
priority: normal
severity: normal
status: open
title: unicodedata.name gives ValueError for control characters
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon Mar  7 11:33:18 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Mar 2022 16:33:18 +0000
Subject: [New-bugs-announce] [issue46948] [CVE-2022-26488] Escalation of
 privilege via Windows Installer
Message-ID: <1646670798.02.0.138739339843.issue46948@roundup.psfhosted.org>


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

CVE-2022-26488 is an escalation of privilege vulnerability in the Windows installer for the following releases of CPython:

* 3.11.0a6 and earlier
* 3.10.2 and earlier
* 3.9.10 and earlier
* 3.8.12 and earlier
* All end-of-life releases of 3.5, 3.6 and 3.7

The vulnerability exists when installed for all users, and when the "Add Python to PATH" option has been selected. A local user without administrative permissions can trigger a repair operation that adds incorrect additional paths to the system PATH variable, and then use search path hijacking to achieve escalation of privilege. Per-user installs (the default) are also affected, but cannot be used for escalation of privilege.

Besides updating, this vulnerability may be mitigated by modifying an existing install to disable the "Add Python to PATH" or "Add Python to environment variables" option. Manually adding the install directory to PATH is not affected.

Thanks to the Lockheed Martin Red Team for detecting and reporting the issue to the Python Security Response Team.

----------
assignee: steve.dower
components: Windows
messages: 414673
nosy: lukasz.langa, ned.deily, pablogsal, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
stage: needs patch
status: open
title: [CVE-2022-26488] Escalation of privilege via Windows Installer
type: security
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/issue46948>
_______________________________________

From report at bugs.python.org  Mon Mar  7 11:52:16 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 07 Mar 2022 16:52:16 +0000
Subject: [New-bugs-announce] [issue46949] Print an indication if traceback
 exceeds sys.tracebacklimit
Message-ID: <1646671936.93.0.679667824145.issue46949@roundup.psfhosted.org>


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

If the number of frames in a traceback exceeds sys.tracebacklimit (which defaults to 1000), any remaining frames are silently dropped. See https://docs.python.org/3.10/library/sys.html#sys.tracebacklimit.

This is confusing to users. We should print some indication like "N additional stack frames not shown".

Here are some specific ideas:
- tracebacklimit <= 0 is documented as dropping the whole traceback. In that case, we don't need too print any message.
- It may be expensive to compute a complete count. Perhaps we can count frames up to 2 * tracebacklimit, and just say "Many additional stack frames not shown".
- The C implementation is in tb_print_internal() in traceback.c, and the Python one in _extract_from_extended_frame_gen in traceback.py.

----------
components: Interpreter Core
messages: 414674
nosy: Jelle Zijlstra, gvanrossum, iritkatriel
priority: normal
severity: normal
status: open
title: Print an indication if traceback exceeds sys.tracebacklimit
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar  7 13:28:51 2022
From: report at bugs.python.org (Darrel O'Pry)
Date: Mon, 07 Mar 2022 18:28:51 +0000
Subject: [New-bugs-announce] [issue46950] Windows 11 venv
Message-ID: <1646677731.73.0.904643383001.issue46950@roundup.psfhosted.org>


New submission from Darrel O'Pry <darrel.opry at spry-group.com>:

I created a virtual env on windows 11. 
When I run pip install -r "..."
I get the error 
```
C:\Users\dopry\src\Client\some.domain.com\django> pip install -r .\requirements_to_freeze.txt
Traceback (most recent call last):
  File "C:\Users\dopry\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\dopry\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Users\dopry\src\Client\some.domain.com\django\venv310\Scripts\pip.exe\__main__.py", line 4, in <module>
ModuleNotFoundError: No module named 'pip'
```

When I run get command to verify that the venv is activated I get

```
(venv310) PS C:\Users\dopry\src\Client\some.domain.com\django> Get-Command python

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     python.exe                                         3.10.21... C:\Users\dopry\src\Client\some.domain.com\django\venv310\Scripts\python.exe
```

When I update the `venv310\pyenv.cfg` and set `include-system-site-packages = true` to true, it was defaulted to false, it seems that I can pip install my requirements successfully. 

When I try to start my app though, the requirements are not found.

----------
components: Windows
messages: 414691
nosy: darrel.opry, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows 11 venv
type: crash
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Mar  7 23:40:32 2022
From: report at bugs.python.org (Henry Finucane)
Date: Tue, 08 Mar 2022 04:40:32 +0000
Subject: [New-bugs-announce] [issue46951] Zipapp contents are in
 filesystem-dependent order
Message-ID: <1646714432.99.0.924297180253.issue46951@roundup.psfhosted.org>


New submission from Henry Finucane <h.finucane at gmail.com>:

Which makes builds non-reproducible. There was some mention of fixing this in https://bugs.python.org/issue30693, but it never got done.

----------
components: Library (Lib)
messages: 414723
nosy: h.finucane
priority: normal
pull_requests: 29864
severity: normal
status: open
title: Zipapp contents are in filesystem-dependent order
type: enhancement
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/issue46951>
_______________________________________

From report at bugs.python.org  Tue Mar  8 00:48:52 2022
From: report at bugs.python.org (=?utf-8?b?66+47IKs7J28?=)
Date: Tue, 08 Mar 2022 05:48:52 +0000
Subject: [New-bugs-announce] [issue46952] pip progress bar display bug
Message-ID: <1646718532.53.0.0764586744515.issue46952@roundup.psfhosted.org>


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

Pip progress bar isn't connect each other and overlap with other components.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 414725
nosy: misileminecord
priority: normal
severity: normal
status: open
title: pip progress bar display bug
versions: Python 3.8

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

From report at bugs.python.org  Tue Mar  8 02:52:36 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Tue, 08 Mar 2022 07:52:36 +0000
Subject: [New-bugs-announce] [issue46953] use FASTCALL for __import__ builtin
Message-ID: <1646725956.31.0.303716044647.issue46953@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Use FASTCALL for __import__ builtin.

Benchmark:
--------------------------------------------------------------------------
import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench __import__",
              stmt="__import__('asyncio')"
------------------------------------------------------------------------

Result:

Mean +- std dev: [base] 191 ns +- 16 ns -> [patch] 112 ns +- 11 ns: 1.71x faster

----------
components: Interpreter Core
messages: 414729
nosy: Dennis Sweeney, Mark.Shannon, kumaraditya303
priority: normal
pull_requests: 29865
severity: normal
status: open
title: use FASTCALL for __import__ builtin
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  8 04:51:03 2022
From: report at bugs.python.org (David M.)
Date: Tue, 08 Mar 2022 09:51:03 +0000
Subject: [New-bugs-announce] [issue46954] Awaiting multiple times on same
 task increases memory usage unboundedly
Message-ID: <1646733063.02.0.0306040798156.issue46954@roundup.psfhosted.org>


New submission from David M. <davidmanz at protonmail.com>:

Awaiting multiple times on a single task that failed with an exception results in an unbounded increase in memory usage. Enough repeated "await"s of the task can result in an OOM.

The same pattern on a task that didn't raise an exception behaves as expected.

The attached short script ends up using more than 1GB of memory in less than a minute.

----------
components: asyncio
files: multi_await_exception.py
messages: 414739
nosy: asvetlov, davidmanzanares, yselivanov
priority: normal
severity: normal
status: open
title: Awaiting multiple times on same task increases memory usage unboundedly
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50664/multi_await_exception.py

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

From report at bugs.python.org  Tue Mar  8 05:01:14 2022
From: report at bugs.python.org (Stefan Zabka)
Date: Tue, 08 Mar 2022 10:01:14 +0000
Subject: [New-bugs-announce] [issue46955] The documentation mentions
 asyncio.Server. It does not exist.
Message-ID: <1646733674.64.0.0195337794151.issue46955@roundup.psfhosted.org>


New submission from Stefan Zabka <szabka at mozilla.com>:

The asyncio documentation claims that there is a class [asyncio.Server](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.Server).

However when looking in the sources I can only find [asyncio.base_events.Server](https://github.com/python/cpython/blob/be095f6c32188bba02079d086ac8639ea37cec3c/Lib/asyncio/base_events.py#L274-L384) which does not get exposed via `__all__` and can not be imported as asyncio.Server.
I had to name the type as I wanted to use this class as a type annotation for mypy.

----------
components: asyncio
messages: 414741
nosy: asvetlov, vringar, yselivanov
priority: normal
severity: normal
status: open
title: The documentation mentions asyncio.Server. It does not exist.
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  8 05:09:03 2022
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgVmFza8Oz?=)
Date: Tue, 08 Mar 2022 10:09:03 +0000
Subject: [New-bugs-announce] [issue46956] TextIOWrapper.seek silently wraps
 around on very large offsets
Message-ID: <1646734143.44.0.894485976083.issue46956@roundup.psfhosted.org>


New submission from L?szl? Vask? <python at accounts.vlaci.email>:

`f.seek()` method may silently wrap around at offsets greater than
`1 << 64` (on AMD64) but return the original seek offset:

    $ strace -e lseek python3
    [...] bunch of strace output
    >>> f = open("/tmp/whatever", "w")
    [...] bunh of strace output
    >>> f.seek((1 << 64) + 1234)
    lseek(3, 1234, SEEK_SET)                = 1234
    18446744073709552850
    >>> _ == (1 << 64) + 1234
    True

When the MSB is set to `1` (e.g. it represents a negative `long`
number) it will indeed overflow and raise on error:

    >>> f.seek((1<<64) - 1)
    lseek(3, -1, SEEK_SET)                  = -1 EINVAL (Invalid argument)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 22] Invalid argument

This causes a confusing behavior that using erroneously big seek
offsets may or may not return an error depending on the MSB value. The
expected behavior would be that both the above calls fail in
accordance with the Zen of Python:

> Errors should never pass silently.
> Unless explicitly silenced.


The issue is only present for text mode files, binary files raise an
error, as expected:

    ValueError: cannot fit 'int' into an offset-sized integer

After some digging I found that the issue comes from `TextIOWrapper`,
particularly from `textiowrapper_parse_cookie(cookie_type *cookie,
PyObject *cookieObj)` calling `PyNumber_Long` silently truncating the
incoming size to 64 bits. The issue can be reproduced on Python 2.7
when using `io.open` in text mode.

----------
components: IO
messages: 414745
nosy: vlaci
priority: normal
severity: normal
status: open
title: TextIOWrapper.seek silently wraps around on very large offsets
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Mar  8 07:45:10 2022
From: report at bugs.python.org (Govinda Totla)
Date: Tue, 08 Mar 2022 12:45:10 +0000
Subject: [New-bugs-announce] [issue46957] Logger with a custom class breaks
 on copy
Message-ID: <1646743510.47.0.936024668329.issue46957@roundup.psfhosted.org>


New submission from Govinda Totla <govinda.totla.cse16 at itbhu.ac.in>:

The logging module allows you set a custom Logger class as the default logger. However, this breaks when we try to copy the logger which was created before setting the logger class

```
import copy
import logging

# Some module we don't control
oldLogger = logging.getLogger("abc")

# Some module where we want to change over to custom logging
class MyLogger(logging.Logger):
    pass

# Override the manager, root, etc., so everything uses our class
logging.setLoggerClass(MyLogger)
logging.root = root = MyLogger("", logging.WARNING)
logging.Logger.manager = logging.Manager(root)

newLogger = logging.getLogger("def")

# Later on this happens, which internally calls __reduce__
copy.deepcopy(oldLogger)
```

----------
components: Library (Lib)
messages: 414750
nosy: govinda18
priority: normal
severity: normal
status: open
title: Logger with a custom class breaks on copy
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar  8 08:59:16 2022
From: report at bugs.python.org (Daniel)
Date: Tue, 08 Mar 2022 13:59:16 +0000
Subject: [New-bugs-announce] [issue46958] json dump/dumps prints each array
 element on a new line (bad for readability)
Message-ID: <1646747956.14.0.613524848103.issue46958@roundup.psfhosted.org>


Change by Daniel <entirity001 at gmail.com>:


----------
components: Library (Lib)
nosy: Entirity
priority: normal
severity: normal
status: open
title: json dump/dumps prints each array element on a new line (bad for readability)
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  8 09:58:43 2022
From: report at bugs.python.org (Barry Davis)
Date: Tue, 08 Mar 2022 14:58:43 +0000
Subject: [New-bugs-announce] [issue46959] ctypes.util.find_library can
 delete /dev/null
Message-ID: <1646751523.29.0.484402205721.issue46959@roundup.psfhosted.org>


New submission from Barry Davis <barry.c.davis at gmail.com>:

This bug exists again: https://bugs.python.org/issue1521375

In ctypes/util we defend against gcc removing /dev/null by using a temp file, but similar code for ld still uses /dev/null, resulting in it removing /dev/null if it has permission, i.e. if running as root.

Reproduction steps in the original bug still work I think.

I found this when running pyinstaller.
I slimmed the test case down to:
 import ctypes.util
 libname = ctypes.util.find_library("ApplicationServices")


Here's my patch (indentation is wrong to just show the actual change needed):

--- Python-3.10.2/Lib/ctypes/util.py    2022-03-08 14:34:52.188808751 +0000
+++ Python-3.10.2/Lib/ctypes/util.py    2022-03-08 14:40:23.604615242 +0000
@@ -305,9 +305,11 @@
             if libpath:
                 for d in libpath.split(':'):
                     cmd.extend(['-L', d])
-            cmd.extend(['-o', os.devnull, '-l%s' % name])
-            result = None
+            temp = tempfile.NamedTemporaryFile()
             try:
+              cmd.extend(['-o', temp.name, '-l%s' % name])
+              result = None
+              try:
                 p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
                                      stderr=subprocess.PIPE,
                                      universal_newlines=True)
@@ -320,8 +322,15 @@
                     if not _is_elf(file):
                         continue
                     return os.fsdecode(file)
-            except Exception:
+              except Exception:
                 pass  # result will be None
+            finally:
+                try:
+                    temp.close()
+                except FileNotFoundError:
+                    # Raised if the file was already removed, which is the normal
+                    # behaviour if linking fails
+                    pass
             return result

         def find_library(name):

----------
components: Library (Lib)
messages: 414756
nosy: barry.c.davis
priority: normal
severity: normal
status: open
title: ctypes.util.find_library can delete /dev/null
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  8 10:32:56 2022
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 08 Mar 2022 15:32:56 +0000
Subject: [New-bugs-announce] [issue46960] Docs: Link from settrace to frame
Message-ID: <1646753576.46.0.958795428095.issue46960@roundup.psfhosted.org>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

https://docs.python.org/3.10/library/sys.html#sys.settrace

> Trace functions should have three arguments: frame, event, and arg. frame is the current stack frame.

It would be super cool, if "current stack frame" could be a hyperlink to the docs about "frame".

----------
messages: 414761
nosy: guettli
priority: normal
severity: normal
status: open
title: Docs: Link from settrace to frame

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

From report at bugs.python.org  Tue Mar  8 10:48:45 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 08 Mar 2022 15:48:45 +0000
Subject: [New-bugs-announce] [issue46961] Caching/interning of small ints
 sometimes fails
Message-ID: <1646754525.83.0.497190179669.issue46961@roundup.psfhosted.org>


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

I'm reluctant to call this a bug, as small int interning/caching is an implementation detail and there are no hard guarantees made.

But on the other hand, it seems that the intention is that small ints such as 0, 1 and 2 should be cached. Here are some examples where they are not. Intentional or a bug?

>>> x = 1
>>> y = pow(2, 31, 2**31-1)
>>> y == x
True
>>> y is x
False


>>> x = 2
>>> y = pow(2, 31, 2**31-2)
>>> y == x
True
>>> y is x
False


It also affects values which are presumably constant-folded at compile time:

>>> x = 1
>>> y = 2**31 % (2**31 - 1)
>>> z = 2**31 % (2**31 - 1)
>>> x == y == z
True
>>> x is y
False
>>> y is z
False
>>> x is z
False



But if you run the code in exec, the value is interned:

>>> code = """
... x = 1
... y = 2**31 % (2**31-1)
... """
>>> dis(code)
  2           0 LOAD_CONST               0 (1)
              2 STORE_NAME               0 (x)

  3           4 LOAD_CONST               0 (1)
              6 STORE_NAME               1 (y)
              8 LOAD_CONST               1 (None)
             10 RETURN_VALUE
>>> exec(code)
>>> x is y
True



Also affects zero:

>>> x = 0
>>> y = 2**29 % (2**29)
>>> x is y
True
>>> y = 2**30 % (2**30)
>>> x is y
False


First noted here:

https://discuss.python.org/t/cached-integer-id-on-high-calculations/14128/1


>>> sys.version
'3.10.0 (default, Oct 28 2021, 20:43:43) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)]'

----------
components: Interpreter Core
messages: 414762
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Caching/interning of small ints sometimes fails
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar  8 13:59:44 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Tue, 08 Mar 2022 18:59:44 +0000
Subject: [New-bugs-announce] [issue46962] Fix docstrings that do not honor
 --without-doc-strings
Message-ID: <1646765984.56.0.127425634873.issue46962@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

To support `--without-doc-strings`, all docstrings must be wrapped into `PyDoc_STRVAR` or `PyDoc_STR` (PEP 7). However, there are 18 occurrences in code and 10 in C API documentation that do not follow this rule. The documentation is important too because it should not teach people the wrong things.

To find the occurrences I searched for `(?:^\s*.tp_doc = "|" \/\* tp_doc \*\/$)` and`^(?:static\s+)?const\s+char\s+[^=]+=\s*"`.

----------
assignee: docs at python
components: Documentation, Extension Modules, Interpreter Core
messages: 414768
nosy: arhadthedev, docs at python
priority: normal
severity: normal
status: open
title: Fix docstrings that do not honor --without-doc-strings
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  8 14:32:14 2022
From: report at bugs.python.org (=?utf-8?b?R2VybcOhbiBNw6luZGV6IEJyYXZv?=)
Date: Tue, 08 Mar 2022 19:32:14 +0000
Subject: [New-bugs-announce] [issue46963] Deep Lazy Imports -
 Interpreter-level deferred module loading
Message-ID: <1646767934.68.0.126950906489.issue46963@roundup.psfhosted.org>


New submission from Germ?n M?ndez Bravo <german.mb at gmail.com>:

As the size of a Python project increases, the number of modules and the complexity of its dependencies increases too, producing two problems in large codebases: increased risk of import cycles and slow start times due to the number of modules that tend to need getting loaded.

We propose implementing a robust and transparent lazy loader in CPython, based on an existing implementation we have in Cinder that proved to be extremely valuable to thousands of developers across Meta, and battle-tested in Instagram Server in production (https://docs.google.com/document/d/1l8I-FDE1xrIShm9eSNJqsGmY_VanMDX5-aK_gujhYBI/edit#heading=h.pu7ja6wu0ib).

Our internal implementation is based on introducing deferred objects and converting top-level imported names to these deferred objects that are evaluated on first use. Enabling this across multiple types of workloads in Meta consistently shown improvements in startup times (up to 70%) and memory footprint (up to 40%), while virtually eliminating occurrences of import cycles.

Converting imported names to deferred objects is a semantic change, and the benefits are usually meaningful only at very large scale, so we propose not changing the default behavior, and making it possible for users to opt-in to this lazy loading mechanism via -x flags or environment variables.

This change would require related documentation changes that would cover the gotchas and edge cases, such as: some packages rely and import-time side-effects for correct operation; nested modules can?t be accessed unless imported explicitly; deferred loading may also defer exceptions from import time and first-access time which could be confusing.

The import-time side effects gotcha can be mitigated using eager-import lists and directives, though it could be desirable to use this as a forcing function to discourage package maintainers from relying on these side-effects.

----------
components: Interpreter Core
messages: 414770
nosy: Kronuz, carljm, dino.viehland, itamaro
priority: normal
severity: normal
status: open
title: Deep Lazy Imports - Interpreter-level deferred module loading
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  8 14:55:53 2022
From: report at bugs.python.org (Eric Snow)
Date: Tue, 08 Mar 2022 19:55:53 +0000
Subject: [New-bugs-announce] [issue46964] The global config should not be
 stored on each interpreter
Message-ID: <1646769353.37.0.654119794325.issue46964@roundup.psfhosted.org>


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

tl;dr let's move PyInterpreterState.config to _PyRuntimeState.config.

Historically the runtime has been initialized using Py_Initialize().  PEP 587 added Py_InitializeFromConfig(), which takes a PyConfig and allows all sorts of customization of the runtime.  This is valuable for embedders (and benefits core development too).

During runtime initialization the given config is copied and stored internally on the main interpreter.  Once initialization completes, the config is no longer modified.  The config values are then used in a variety of places during execution.  If a new interpreter is created then the config from the current (or main) interpreter are copied into it.

Note the following:

* the config is never modified
* there is no public API for getting the config or changing it
* there is no API for creating an interpreter with a different config
* the fact that the config is stored on the interpreter is an internal detail and not documented (nor discussed in PEP 587)

Consequently, PyConfig really is the global runtime config.  Yet we are storing a copy of it on each interpreter.  Doing so unnecessarily adds extra complexity (and, when multiple interpreters are used, extra CPU usage and extra memory usage).

So I propose that we move the config to _PyRuntimeState.  The change isn't big nor all that complex.  Note that actually there is one field that can differ between interpreters: PyConfig._isolated_interpreter (set in _Py_NewInterpreter()).  We can move that one field to a new per-interpreter config struct.

----------
assignee: eric.snow
components: C API, Interpreter Core
messages: 414772
nosy: eric.snow, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: The global config should not be stored on each interpreter
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  8 19:37:24 2022
From: report at bugs.python.org (Dino Viehland)
Date: Wed, 09 Mar 2022 00:37:24 +0000
Subject: [New-bugs-announce] [issue46965] Enable informing callee it's
 awaited via vector call flag
Message-ID: <1646786244.6.0.865955728693.issue46965@roundup.psfhosted.org>


New submission from Dino Viehland <dinoviehland at gmail.com>:

The idea here is to add a new flag to the vectorcall nargs that indicates the call is being awaited: _Py_AWAITED_CALL_MARKER.  This flag will allow the callee to know that it's being eagerly evaluated.  When the call is eagerly evaluated the callee can potentially avoid various amounts of overhead.  For a coroutine the function can avoid creating the coroutine object and instead returns a singleton instance of a wait handle indicating eager execution has occurred:
https://github.com/facebookincubator/cinder/blob/cinder/3.8/Python/ceval.c#L6617

This gives a small win by reducing the overhead of allocating the co-routine object.

For something like gather much more significant wins can be achieved.  If all of the inputs have already been computed the creation of tasks and scheduling of them to the event loop can be elided.  An example implementation of this is available in Cinder: https://github.com/facebookincubator/cinder/blob/cinder/3.8/Modules/_asynciomodule.c#L7103

Again the gather implementation uses the singleton wait handle object to return the value indicating the computation completed synchronously.

We've used this elsewhere in Cinder as well - for example if we have an "AsyncLazyValue" which lazily performs a one-time computation of a value   and caches it.  Therefore the common case becomes that the value is already available, and the await can be performed without allocating any intermediate values.

----------
assignee: dino.viehland
messages: 414782
nosy: Mark.Shannon, carljm, dino.viehland, gvanrossum, itamaro
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable informing callee it's awaited via vector call flag
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar  8 21:28:03 2022
From: report at bugs.python.org (JP Sugarbroad)
Date: Wed, 09 Mar 2022 02:28:03 +0000
Subject: [New-bugs-announce] [issue46966] c_void_p array is a footgun on
 I32LP64 systems
Message-ID: <1646792883.64.0.681602765886.issue46966@roundup.psfhosted.org>


New submission from JP Sugarbroad <taralx at gmail.com>:

The following code will likely crash on I32LP64 systems:

dim = lib.get_array_size(opaque)
ptrs = (c_void_p * dim)()
lib.get_array_values(opaque, ptrs)
for ptr in ptrs:
    print(lib.get_object_value(ptr))

What happens is that `ptr` is not a `c_void_p` -- it's just a bare number. And when it's passed to another function it goes in as a (32-bit) `c_int`, resulting in a truncation.

I'm not sure what can be done here (maybe a truncation warning?) but it's definitely a difficult bug to notice when reviewing code.

----------
components: ctypes
messages: 414783
nosy: taralx
priority: normal
severity: normal
status: open
title: c_void_p array is a footgun on I32LP64 systems
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Mar  9 12:49:02 2022
From: report at bugs.python.org (Henry Schreiner)
Date: Wed, 09 Mar 2022 17:49:02 +0000
Subject: [New-bugs-announce] [issue46967] Type union for except
Message-ID: <1646848142.9.0.223249735581.issue46967@roundup.psfhosted.org>


New submission from Henry Schreiner <henryschreineriii at gmail.com>:

In 3.10 via PEP 604, there was an attempt to use the new union of types where runtime types were previously expected to be a tuple. `isinstance(x, (A, B))` can be written `isinstance(x, A | B)`. Unfortunately, there still is a case were a tuple of types is required: `except (A, B) as err:` cannot be written `except A | B as err:`. I think this should be allowed; it is consistent with isinstance and pattern matching's use of |, and nicely avoids confusion with `except A, B:` which is disallowed for Python 2 reasons; `except A | B`: would be valid.

----------
components: Interpreter Core
messages: 414807
nosy: Henry Schreiner
priority: normal
severity: normal
status: open
title: Type union for except
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar  9 14:07:02 2022
From: report at bugs.python.org (Oleksandr Pavlyk)
Date: Wed, 09 Mar 2022 19:07:02 +0000
Subject: [New-bugs-announce] [issue46968] Insufficient sigaltstack size used
 by CPython prevents extensions from using new ISA
Message-ID: <1646852822.75.0.964834360067.issue46968@roundup.psfhosted.org>


New submission from Oleksandr Pavlyk <oleksandr.pavlyk at intel.com>:

The following snippet illustrates request by an extension to use AMX registers:

```
// no increase sigaltstack size fix will not wark till we fix python
void enable_amx_no_fix()
{

    unsigned long bitmask;
    long rc;

    rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, XFEATURE_XTILEDATA);
    if (rc) {
        printf("The kernel rejects the AMX use.\n");
        printf("errno %d\n",errno);
    } else {
        printf("The kernel allows to use AMX.\n");
    }


    rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_PERM, &bitmask);

    if (rc) {
        printf("rc error\n");
    } else  {
        if (( bitmask & XFEATURE_MASK_XTILEDATA) == 0){
            printf("verify AMX permission faild bitmask %ld\n",bitmask);
        }

    }
}
```

This request fails on the account of too small a size for sigaltstack used by CPython allocated in Modules/faulthandler.c

The stack size used is 2*SIGSTKSZ, and does not take hardware capabilities into account.

Linux kernel 5.14 adds support to query minimum size of sigaltstack dynamically via getauxval(AT_MINSIGSTKSZ).

AMX support is added in Linux kernel 5.16 

CPython should make use of this when built against more recent Linux kernels.

----------
components: Extension Modules
messages: 414809
nosy: oleksandr-pavlyk
priority: normal
severity: normal
status: open
title: Insufficient sigaltstack size used by CPython prevents extensions from using new ISA
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Mar  9 16:04:13 2022
From: report at bugs.python.org (Dutcho)
Date: Wed, 09 Mar 2022 21:04:13 +0000
Subject: [New-bugs-announce] [issue46969] `pip install wrapt` fails on
 ast.py in Python 3.11.0a6
Message-ID: <1646859853.98.0.761259079796.issue46969@roundup.psfhosted.org>


New submission from Dutcho <dutcho at ziggo.nl>:

... or perhaps this is caused by *wrapt 1.13.3*?

'''
(venv) >pip install wrapt
Collecting wrapt
  Using cached wrapt-1.13.3.tar.gz (48 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  ? python setup.py egg_info did not run successfully.
  ? exit code: 1
  ??> [92 lines of output]
      Traceback (most recent call last):
        File "...\venv\Lib\site-packages\setuptools\config.py", line 35, in __getattr__
          return next(
                 ^^^^^
        File "...\venv\Lib\site-packages\setuptools\config.py", line 36, in <genexpr>
          ast.literal_eval(statement.value)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Program Files\Python311\Lib\ast.py", line 108, in literal_eval
          return _convert(node_or_string)
                 ^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Program Files\Python311\Lib\ast.py", line 107, in _convert
          return _convert_signed_num(node)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Program Files\Python311\Lib\ast.py", line 81, in _convert_signed_num
          return _convert_num(node)
                 ^^^^^^^^^^^^^^^^^^
        File "C:\Program Files\Python311\Lib\ast.py", line 72, in _convert_num
          _raise_malformed_node(node)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Program Files\Python311\Lib\ast.py", line 69, in _raise_malformed_node
          raise ValueError(msg + f': {node!r}')
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      ValueError: malformed node or string on line 2: <ast.Call object at 0x000001751FEA8340>
'''

----------
messages: 414814
nosy: Dutcho
priority: normal
severity: normal
status: open
title: `pip install wrapt` fails on ast.py in Python 3.11.0a6
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar  9 19:14:28 2022
From: report at bugs.python.org (Guido Imperiale)
Date: Thu, 10 Mar 2022 00:14:28 +0000
Subject: [New-bugs-announce] [issue46970] dataclass(slots=True) incompatible
 with __init_subclass__
Message-ID: <1646871268.44.0.752243680587.issue46970@roundup.psfhosted.org>


New submission from Guido Imperiale <crusaderky at gmail.com>:

Related to #46382
A class decorated with dataclass(slots=True) can't pass any parameters to the __init_subclass__ method of its parent class.


from dataclasses import dataclass

class A:
    __slots__ = ()
    def __init_subclass__(cls, msg):
        print(msg)

@dataclass(slots=True)
class B(A, msg="Hello world!"):
    pass


  File "lib/python3.10/dataclasses.py", line 1145, in _add_slots
    cls = type(cls)(cls.__name__, cls.__bases__, cls_dict)
TypeError: A.__init_subclass__() missing 1 required positional argument: 'msg'

----------
components: Library (Lib)
messages: 414822
nosy: crusaderky
priority: normal
severity: normal
status: open
title: dataclass(slots=True) incompatible with __init_subclass__
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar 10 04:40:49 2022
From: report at bugs.python.org (Hu Di)
Date: Thu, 10 Mar 2022 09:40:49 +0000
Subject: [New-bugs-announce] [issue46971] python takes long time when return
 big data
Message-ID: <1646905249.02.0.757462069479.issue46971@roundup.psfhosted.org>


Change by Hu Di <476658825 at qq.com>:


----------
components: Interpreter Core
nosy: HumberMe
priority: normal
severity: normal
status: open
title: python takes long time when return big data
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar 10 04:44:46 2022
From: report at bugs.python.org (Thomas Fischbacher)
Date: Thu, 10 Mar 2022 09:44:46 +0000
Subject: [New-bugs-announce] [issue46972] Documentation: Reference says
 AssertionError is raised by `assert`, but not all AssertionErrors are.
Message-ID: <1646905486.67.0.783441302019.issue46972@roundup.psfhosted.org>


New submission from Thomas Fischbacher <tfish at google.com>:

The Python reference says:

(1) https://docs.python.org/3/library/exceptions.html#concrete-exceptions

exception AssertionError
Raised when an assert statement fails.

(2) https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement

"assert ..." is equivalent to "if __debug__: ..."

>From this, one can infer the guarantee "the -O flag will suppress AssertionError exceptions from being raised".

However, there is code in the Python standard library that does a direct "raise AssertionError" (strictly speaking, in violation of (1)), and it is just reasonable to assume that other code following the design of that would then also want to do a direct "raise AssertionError".

This happens e.g. in many methods defined in: unittest/mock.py

The most appropriate fix here may be to change the documentation to not say:

===
exception AssertionError
Raised when an assert statement fails.
===

but instead:

===
exception AssertionError
An assert[{add reference to `assert` definition}] statement fails, or a unit testing related assert{...}() callable detects an assertion violation.
===

----------
messages: 414837
nosy: tfish2
priority: normal
severity: normal
status: open
title: Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

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

From report at bugs.python.org  Thu Mar 10 08:29:14 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Mar 2022 13:29:14 +0000
Subject: [New-bugs-announce] [issue46973] Provide make target to regenerate
 autoconf files with container
Message-ID: <1646918954.08.0.6866798038.issue46973@roundup.psfhosted.org>


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

CPython stores auto-generated autoconf files (configure, aclocal.m4, pyconfig.h.in) in git. The files must be regenerated with very specific versions of autotools 2.69 + runtimestate patch, autoarchive, and pkg-config's m4 macros. I provide a container image based on Alpine 3.13 for automation and CI.

Let's add a build target to make it easier for contributors to regenerate the files and utilize the container images. The command needs a container runtime (podman, docker), though.

----------
assignee: christian.heimes
components: Build
messages: 414846
nosy: brett.cannon, christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: Provide make target to regenerate autoconf files with container
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Mar 10 09:07:15 2022
From: report at bugs.python.org (PiTeR)
Date: Thu, 10 Mar 2022 14:07:15 +0000
Subject: [New-bugs-announce] [issue46974] set function for lists on numbers,
 sometimes sorts elements from smallest to largest, and sometimes not
Message-ID: <1646921235.45.0.756615135593.issue46974@roundup.psfhosted.org>


New submission from PiTeR <pio.paluchowski at wp.pl>:

set function for lists on numbers, sometimes sorts elements from smallest to largest, and sometimes not
to find this bug, sometimes you need to display the result several times
example code:
def tupla():
    import random
    ilosc = random.randint(0,49)
    n=0
    lista=[]
    i=0
    while True:
        n = random.randint(1,100)
        lista.append(n)
        i=i+1
        if i==ilosc-1:
            break
    lista = set(lista)
    list(lista)
    print(lista)

----------
components: Windows
files: bug_1.PNG
messages: 414848
nosy: paul.moore, pio.paluchowski, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: set function for lists on numbers, sometimes sorts elements from smallest to largest, and sometimes not
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50666/bug_1.PNG

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

From report at bugs.python.org  Thu Mar 10 11:38:01 2022
From: report at bugs.python.org (Battant)
Date: Thu, 10 Mar 2022 16:38:01 +0000
Subject: [New-bugs-announce] [issue46975] clang: error: linker command
 failed with exit code 1 (use -v to see invocation) on m1 mac
Message-ID: <1646930281.31.0.068215142849.issue46975@roundup.psfhosted.org>


New submission from Battant <mparchet at sunrise.ch>:

Hello,

Here is my configuration

mac os 12.2.1
mac m1 pro 2021

step to reproduce
1. on mac m1, clone cpython repository main branch
run
./confugure
make
Actual result :
gcc   -fno-semantic-interposition -fprofile-instr-generate -Wl,-stack_size,1000000  -framework CoreFoundation -o python.exe Programs/python.o libpython3.10d.a -ldl   -framework CoreFoundation    
gcc   -fno-semantic-interposition -fprofile-instr-generate -Wl,-stack_size,1000000  -framework CoreFoundation -o Programs/_testembed Programs/_testembed.o libpython3.10d.a -ldl   -framework CoreFoundation    
Undefined symbols for architecture arm64:
  "_libintl_bindtextdomain", referenced from:
Undefined symbols for architecture arm64:
  "_libintl_bindtextdomain", referenced from:
      __locale_bindtextdomain_impl in libpython3.10d.a(_localemodule.o)
      __locale_bindtextdomain_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
  "_libintl_dcgettext", referenced from:
      __locale_dcgettext_impl in libpython3.10d.a(_localemodule.o)
      __locale_dcgettext_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
  "_libintl_dgettext", referenced from:
      __locale_dgettext_impl in libpython3.10d.a(_localemodule.o)
      __locale_dgettext_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_gettext", referenced from:
  "_libintl_gettext", referenced from:
      __locale_gettext_impl in libpython3.10d.a(_localemodule.o)
      __locale_gettext_impl in libpython3.10d.a(_localemodule.o)
  "_libintl_setlocale", referenced from:
  "_libintl_setlocale", referenced from:
      __locale_setlocale_impl in libpython3.10d.a(_localemodule.o)
      _locale_decode_monetary in libpython3.10d.a(_localemodule.o)
      __locale_setlocale_impl in libpython3.10d.a(_localemodule.o)
      _locale_decode_monetary in libpython3.10d.a(_localemodule.o)
  "_libintl_textdomain", referenced from:
  "_libintl_textdomain", referenced from:
      __locale_textdomain_impl in libpython3.10d.a(_localemodule.o)
      __locale_textdomain_impl in libpython3.10d.a(_localemodule.o)
ld: symbol(s) not found for architecture arm64
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [python.exe] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [Programs/_testembed] Error 1
make[2]: *** [build_all_generate_profile] Error 2
make[1]: *** [profile-gen-stamp] Error 2
make: *** [profile-run-stamp] Error 2

Could you help me please to fix this issus ?

Best regards

Battant

----------
components: macOS
messages: 414859
nosy: Battant, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 10 12:07:20 2022
From: report at bugs.python.org (Ned Deily)
Date: Thu, 10 Mar 2022 17:07:20 +0000
Subject: [New-bugs-announce] [issue46976] Update macOS installer builds to
 use ncurses 6.3
Message-ID: <1646932040.18.0.686827963396.issue46976@roundup.psfhosted.org>


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

The python.org macOS installers include a private copy of the ncurses library; it has not been updated from 5.9 in a long time. The current upstream version is 6.3 and includes bug and security fixes; we should update to it.

----------
components: macOS
messages: 414869
nosy: ned.deily, ronaldoussoren
priority: high
severity: normal
stage: needs patch
status: open
title: Update macOS installer builds to use ncurses 6.3
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Mar 10 12:22:08 2022
From: report at bugs.python.org (Alexandre Feblot)
Date: Thu, 10 Mar 2022 17:22:08 +0000
Subject: [New-bugs-announce] [issue46977] tempfile.TemporaryDirectory fails
 removing dir in some edge cases related to symlinks
Message-ID: <1646932928.52.0.00833614207853.issue46977@roundup.psfhosted.org>


New submission from Alexandre Feblot <alexandre.feblot at gmail.com>:

```python
#!/usr/bin/env python3

import os
import tempfile

def createUnremovableDir(workdir):
    print(workdir)
    os.mkdir(f'{workdir}/mydir')
    os.symlink('/bin/bash', f'{workdir}/mydir/mylink') # Symlink to a root owned file
    os.chmod(f'{workdir}/mydir', 0o555)

with tempfile.TemporaryDirectory() as workdir:
    createUnremovableDir(workdir)
```

Fails because `tempfile.TemporaryDirectory._rmtree` tries to execute os.chmod(path, 0o700) on the symlink, which by default tries to change the root owned file symlink target instead of the symlink itself:

```
/tmp/tmp1_dy42ef
Traceback (most recent call last):
  File "/usr/lib/python3.9/shutil.py", line 682, in _rmtree_safe_fd
    os.unlink(entry.name, dir_fd=topfd)
PermissionError: [Errno 13] Permission denied: 'mylink'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "~/tempfile_demo_bug.py", line 13, in <module>
    createUnremovableDir(workdir)
  File "/usr/lib/python3.9/tempfile.py", line 969, in __exit__
    self.cleanup()
  File "/usr/lib/python3.9/tempfile.py", line 973, in cleanup
    self._rmtree(self.name)
  File "/usr/lib/python3.9/tempfile.py", line 955, in _rmtree
    _rmtree(name, onerror=onerror)
  File "/usr/lib/python3.9/shutil.py", line 727, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.9/shutil.py", line 664, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 684, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/usr/lib/python3.9/tempfile.py", line 941, in onerror
    resetperms(path)
  File "/usr/lib/python3.9/tempfile.py", line 936, in resetperms
    _os.chmod(path, 0o700)
PermissionError: [Errno 1] Operation not permitted: '/tmp/tmp1_dy42ef/mydir/mylink'
```

and leaves:

```
(.venv python 3.9.9) $ find /tmp/tmp1_dy42ef -ls
   148228      4 drwx------   3 myuser myuser     4096 Mar 10 16:54 /tmp/tmp1_dy42ef
   148229      4 drwx------   2 myuser myuser     4096 Mar 10 16:54 /tmp/tmp1_dy42ef/mydir
   148230      0 lrwxrwxrwx   1 myuser myuser        9 Mar 10 16:54 /tmp/tmp1_dy42ef/mydir/mylink -> /bin/bash

```

This fixes it:

``` python
#!/usr/bin/env python3

import os
import tempfile

def createUnremovableDir(workdir):
    print(workdir)
    os.mkdir(f'{workdir}/mydir')
    os.symlink('/bin/bash', f'{workdir}/mydir/mylink') # Symlink to a root owned file
    os.chmod(f'{workdir}/mydir', 0o555)

def _rmtree(cls, name, ignore_errors=False):
    def onerror(func, path, exc_info):
        if issubclass(exc_info[0], PermissionError):
            def resetperms(path):
                try:
                    if os.chflags in os.supports_follow_symlinks:  # This is the patch
                        os.chflags(path, 0, follow_symlinks=False) # This is the patch
                    elif not os.path.islink(path):                 # This is the patch
                        os.chflags(path, 0)
                except AttributeError:
                    pass
                if os.chmod in os.supports_follow_symlinks:        # This is the patch
                    os.chmod(path, 0o700, follow_symlinks=False)   # This is the patch
                elif not os.path.islink(path):                     # This is the patch
                    os.chmod(path, 0o700)

            try:
                if path != name:
                    resetperms(os.path.dirname(path))
                resetperms(path)

                try:
                    os.unlink(path)
                # PermissionError is raised on FreeBSD for directories
                except (IsADirectoryError, PermissionError):
                    cls._rmtree(path, ignore_errors=ignore_errors)
            except FileNotFoundError:
                pass
        elif issubclass(exc_info[0], FileNotFoundError):
            pass
        else:
            if not ignore_errors:
                raise

    shutil.rmtree(name, onerror=onerror)

# Monkey patch the class method tempfile.TemporaryDirectory._rmtree
from types import MethodType
import shutil
tempfile.TemporaryDirectory._rmtree = MethodType(_rmtree, tempfile.TemporaryDirectory)

with tempfile.TemporaryDirectory() as workdir:
    createUnremovableDir(workdir)

----------
components: Library (Lib)
messages: 414871
nosy: afeblot
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory fails removing dir in some edge cases related to symlinks
versions: Python 3.9

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

From report at bugs.python.org  Thu Mar 10 14:36:25 2022
From: report at bugs.python.org (Nicko van Someren)
Date: Thu, 10 Mar 2022 19:36:25 +0000
Subject: [New-bugs-announce] [issue46978] Doc strings for built-in,
 in-place operators are misleading
Message-ID: <1646940985.13.0.430689283969.issue46978@roundup.psfhosted.org>


New submission from Nicko van Someren <nicko at nicko.org>:

Objects/typeobject.c uses slots to implement various operators and the IBSLOT macro is used to define slot entries for in-place binary operators. This macro creates a __doc__ string for the operators of the form "Return self<op>value."

This doc string is misleading since an in-place operator statement can not be used as an L-value, so nothing is "returned".

To fix this, the macro definition for IBSLOT should be updated to use a different word or phrase, such as "Compute self<op>value."

----------
components: Interpreter Core
messages: 414876
nosy: nickovs
priority: normal
severity: normal
status: open
title: Doc strings for built-in, in-place operators are misleading
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar 10 15:43:20 2022
From: report at bugs.python.org (Bankole Jesutofunmi)
Date: Thu, 10 Mar 2022 20:43:20 +0000
Subject: [New-bugs-announce] [issue46979] Master piece
Message-ID: <1646945000.99.0.420885762408.issue46979@roundup.psfhosted.org>


New submission from Bankole Jesutofunmi <aanuoluwapobankole1104 at gmail.com>:

Protection

----------
components: Build, Demos and Tools
messages: 414878
nosy: Banky_1104, teoliphant
priority: normal
severity: normal
status: open
title: Master piece
type: security
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar 10 22:08:56 2022
From: report at bugs.python.org (Ruishi)
Date: Fri, 11 Mar 2022 03:08:56 +0000
Subject: [New-bugs-announce] [issue46980] ast.FunctionDef cannot find
 functions under if statement
Message-ID: <1646968136.79.0.973896459669.issue46980@roundup.psfhosted.org>


New submission from Ruishi <summerlinasity at gmail.com>:

When I use the Python ast package to get the functions of Python files, I find the functions defined in the body of `if` statement cannot be recognized.

Here is my code:
with open(py_file, 'r') as f:
    data = f.read()
    module = ast.parse(data)
    func_def = [node for node in module.body if isinstance(node, ast.FunctionDef)]

Here is an example of Python file:
if supports_bytes_environ:
    def _check_bytes(value):
        if not isinstance(value, bytes):
            raise TypeError("bytes expected, not %s" % type(value).__name__)
        return value

The function `_check_bytes` is not in `func_def`. I also tested `ast.iter_child_nodes(module)` and it also has this issue.

----------
components: Parser
messages: 414886
nosy: Ruishi, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: ast.FunctionDef cannot find functions under if statement
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Fri Mar 11 03:21:12 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2022 08:21:12 +0000
Subject: [New-bugs-announce] [issue46981] Empty typing.Tuple
Message-ID: <1646986872.43.0.932223345125.issue46981@roundup.psfhosted.org>


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

There are two empty typing.Tuple. They have the same repr but are not equal.

>>> from typing import *
>>> t1 = Tuple[()]
>>> t2 = t1.copy_with(())
>>> t1
typing.Tuple[()]
>>> t2
typing.Tuple[()]
>>> t1 == t2
False
>>> t1.__args__
((),)
>>> t2.__args__
()

The only differences is that one has empty __args__, while other has __args__ containing an empty tuple. There is a code purposed to make __args__ containing an empty tuple in this case. What is the purpose?

It is not pure theoretical question. This affects unpacked TypeVarTuple substitution. With natural implementation Tuple[Unpack[Ts]][()] is not equal to Tuple[()] and I still have not figured which and where code should be added to handle this special case. It would be easier if such special case did not exist.

Built-in tuple does not have a special case:

>>> tuple[()].__args__
()

----------
components: Library (Lib)
messages: 414892
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Empty typing.Tuple

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

From report at bugs.python.org  Fri Mar 11 03:25:03 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Mar 2022 08:25:03 +0000
Subject: [New-bugs-announce] [issue46982] Error in the experts list
Message-ID: <1646987103.96.0.139741803932.issue46982@roundup.psfhosted.org>


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

After adding experts for typing module, I get an error when try to submit changes:

   Error: property nosy: 'JelleZijlstra' is not a user.

I think there is a typo in the experts list.

----------
messages: 414893
nosy: gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Error in the experts list

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

From report at bugs.python.org  Fri Mar 11 07:24:41 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2022 12:24:41 +0000
Subject: [New-bugs-announce] [issue46983] test_sqlite3:
 test_trace_too_much_expanded_sql() failed on AMD64 Arch Linux Usan 3.x
Message-ID: <1647001481.77.0.569348369265.issue46983@roundup.psfhosted.org>


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

AMD64 Arch Linux Usan 3.x:
https://buildbot.python.org/all/#/builders/719/builds/672

Python configured with:

./configure CC=clang LD=clang CFLAGS=-fno-sanitize-recover --with-undefined-behavior-sanitizer

0:12:11 load avg: 1.63 Re-running test_sqlite3 in verbose mode (matching: test_trace_too_much_expanded_sql)
test_sqlite3: testing with version '2.6.0', sqlite_version '3.37.0'
test_trace_too_much_expanded_sql (test.test_sqlite3.test_hooks.TraceCallbackTests) ... FAIL

======================================================================
FAIL: test_trace_too_much_expanded_sql (test.test_sqlite3.test_hooks.TraceCallbackTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/test/test_sqlite3/test_userfunctions.py", line 62, in check_tracebacks
    yield
    ^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/test/test_sqlite3/test_userfunctions.py", line 47, in wrapper
    func(self, *args, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/test/test_sqlite3/test_dbapi.py", line 61, in cx_limit
    yield limit
    ^^^^^^^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/test/test_sqlite3/test_hooks.py", line 338, in test_trace_too_much_expanded_sql
    with self.check_stmt_trace(cx, [unexpanded_query]):
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/contextlib.py", line 144, in __exit__
    next(self.gen)
    ^^^^^^^^^^^^^^
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Lib/test/test_sqlite3/test_hooks.py", line 238, in check_stmt_trace
    self.assertEqual(traced, expected)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Lists differ: ['sel[41 chars] "a"=\'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[39 chars]a\''] != ['sel[41 chars] "a"=?']

First differing element 0:
'sele[40 chars] "a"=\'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[38 chars]aa\''
'sele[40 chars] "a"=?'

- ['select \'b\' as "a" from sqlite_master where '
+ ['select \'b\' as "a" from sqlite_master where "a"=?']
?                                                +++++ +

-  '"a"=\'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\'']

----------
components: Library (Lib)
messages: 414900
nosy: erlendaasland, vstinner
priority: normal
severity: normal
status: open
title: test_sqlite3: test_trace_too_much_expanded_sql() failed on AMD64 Arch Linux Usan 3.x
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 11 07:27:27 2022
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2022 12:27:27 +0000
Subject: [New-bugs-announce] [issue46984] test_concurrent_futures logs many
 UndefinedBehaviorSanitizer "DEADLYSIGNAL" errors on AMD64 Arch Linux Usan
 3.x
Message-ID: <1647001647.41.0.938869406277.issue46984@roundup.psfhosted.org>


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

AMD64 Arch Linux Usan 3.x:
https://buildbot.python.org/all/#/builders/719/builds/672

I don't know if ASAN_OPTIONS env var is set on this buildbot. test.pythoninfo doesn't log ASAN_OPTIONS env var.

0:04:22 load avg: 1.30 [130/433] test_concurrent_futures passed (2 min 48 sec) -- running: test_multiprocessing_fork (44.3 sec)
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==348616==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e8000551c8 (pc 0x7fec1ffcc702 bp 0x000000000000 sp 0x7ffc39f5d020 T348616)
==348616==The signal is caused by a READ memory access.
    #0 0x7fec1ffcc702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x555e6be87c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x555e6be87c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x555e6bce3c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #9 0x7fec1e2fca2d in load_reduce /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:6761:15
    #10 0x7fec1e2fca2d in load /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:6909:9
    #11 0x7fec1e2f23b7 in _pickle_loads_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:7861:14
    #12 0x7fec1e2f23b7 in _pickle_loads /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/clinic/_pickle.c.h:834:20
    #13 0x555e6bce2d27 in cfunction_vectorcall_FASTCALL_KEYWORDS /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:443:24
    #14 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #15 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #16 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #17 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #18 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #19 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #20 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #21 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #22 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #23 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #24 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #25 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #26 0x555e6bd1bcf4 in slot_tp_init /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7802:15
    #27 0x555e6bd07c21 in type_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:1116:19
    #28 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #29 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #30 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #31 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #32 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #33 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #34 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #35 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #36 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #37 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #38 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #39 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #40 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #41 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #42 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #43 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #44 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #45 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #46 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #47 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #48 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #49 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #50 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #51 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #52 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #53 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #54 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #55 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #56 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #57 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #58 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #59 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #60 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #61 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #62 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #63 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #64 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #65 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #66 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #67 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #68 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #69 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #70 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #71 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #72 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #73 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #74 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #75 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #76 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #77 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #78 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #79 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #80 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #81 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #82 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #83 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #84 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #85 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #86 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #87 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #88 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #89 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #90 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #91 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #92 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #93 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #94 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #95 0x555e6bf0d044 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #96 0x555e6bf0e5b2 in partial_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/_functoolsmodule.c:223:16
    #97 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #98 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #99 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #100 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #101 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #102 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #103 0x555e6bc71d53 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:52:18
    #104 0x555e6bc6e182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #105 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #106 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #107 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #108 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #109 0x555e6bdc4abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #110 0x555e6bdbf5c8 in builtin_exec_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/bltinmodule.c:1040:13
    #111 0x555e6bdbf5c8 in builtin_exec /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/clinic/bltinmodule.c.h:371:20
    #112 0x555e6bce2bf3 in cfunction_vectorcall_FASTCALL /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:427:24
    #113 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #114 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #115 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #116 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #117 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #118 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #119 0x555e6be802ac in pymain_run_module /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:293:14
    #120 0x555e6be7f6c0 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c
    #121 0x555e6be7f6c0 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #122 0x555e6be80059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #123 0x555e6be80106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #124 0x7fec1fdecb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #125 0x555e6bbce69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==348616==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==348627==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e8000551d3 (pc 0x7fec1ffcc702 bp 0x000000000000 sp 0x7ffc39f5d1e0 T348627)
==348627==The signal is caused by a READ memory access.
    #0 0x7fec1ffcc702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x555e6be87c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x555e6be87c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x555e6bce3c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #9 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #10 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #11 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #12 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #13 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #14 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #15 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #16 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #17 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #18 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #19 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #20 0x555e6bd1bcf4 in slot_tp_init /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7802:15
    #21 0x555e6bd07c21 in type_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:1116:19
    #22 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #23 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #24 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #25 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #26 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #27 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #28 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #29 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #30 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #31 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #32 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #33 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #34 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #35 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #36 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #37 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #38 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #39 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #40 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #41 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #42 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #43 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #44 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #45 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #46 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #47 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #48 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #49 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #50 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #51 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #52 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #53 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #54 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #55 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #56 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #57 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #58 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #59 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #60 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #61 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #62 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #63 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #64 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #65 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #66 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #67 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #68 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #69 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #70 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #71 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #72 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #73 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #74 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #75 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #76 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #77 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #78 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #79 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #80 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #81 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #82 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #83 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #84 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #85 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #86 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #87 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #88 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #89 0x555e6bf0d044 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #90 0x555e6bf0e5b2 in partial_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/_functoolsmodule.c:223:16
    #91 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #92 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #93 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #94 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #95 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #96 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #97 0x555e6bc71d53 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:52:18
    #98 0x555e6bc6e182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #99 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #100 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #101 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #102 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #103 0x555e6bdc4abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #104 0x555e6bdbf5c8 in builtin_exec_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/bltinmodule.c:1040:13
    #105 0x555e6bdbf5c8 in builtin_exec /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/clinic/bltinmodule.c.h:371:20
    #106 0x555e6bce2bf3 in cfunction_vectorcall_FASTCALL /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:427:24
    #107 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #108 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #109 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #110 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #111 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #112 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #113 0x555e6be802ac in pymain_run_module /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:293:14
    #114 0x555e6be7f6c0 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c
    #115 0x555e6be7f6c0 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #116 0x555e6be80059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #117 0x555e6be80106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #118 0x7fec1fdecb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #119 0x555e6bbce69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==348627==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==348638==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e8000551de (pc 0x7fec1ffcc702 bp 0x000000000000 sp 0x7ffc39f5cdb0 T348638)
==348638==The signal is caused by a READ memory access.
    #0 0x7fec1ffcc702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x555e6be87c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x555e6be87c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x555e6bce3c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #9 0x555e6bc71d90 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:60:20
    #10 0x555e6bd113c3 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #11 0x555e6bd1476d in _PyObject_CallNoArgs /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:107:12
    #12 0x555e6bd1476d in object___reduce_ex___impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:5421:19
    #13 0x555e6bce3136 in cfunction_vectorcall_O /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:513:24
    #14 0x555e6bc6e7b3 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #15 0x555e6bc6e7b3 in PyObject_CallOneArg /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:375:12
    #16 0x7fec1e2f407c in _Pickle_FastCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:374:14
    #17 0x7fec1e2f407c in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4419:32
    #18 0x7fec1e2f5720 in batch_dict_exact /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:3279:17
    #19 0x7fec1e2f5720 in save_dict /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:3333:22
    #20 0x7fec1e2f3d72 in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4311:18
    #21 0x7fec1e2f8426 in save_reduce /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4217:17
    #22 0x7fec1e2f3f8a in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4456:14
    #23 0x7fec1e2f2d8a in dump /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4502:9
    #24 0x7fec1e30437f in _pickle_Pickler_dump /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4573:9
    #25 0x555e6bdc8bcb in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5106:29
    #26 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #27 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #28 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #29 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #30 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #31 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #32 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #33 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #34 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #35 0x555e6bd1bcf4 in slot_tp_init /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7802:15
    #36 0x555e6bd07c21 in type_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:1116:19
    #37 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #38 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #39 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #40 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #41 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #42 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #43 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #44 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #45 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #46 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #47 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #48 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #49 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #50 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #51 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #52 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #53 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #54 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #55 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #56 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #57 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #58 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #59 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #60 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #61 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #62 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #63 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #64 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #65 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #66 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #67 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #68 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #69 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #70 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #71 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #72 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #73 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #74 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #75 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #76 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #77 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #78 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #79 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #80 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #81 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #82 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #83 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #84 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #85 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #86 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #87 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #88 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #89 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #90 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #91 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #92 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #93 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #94 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #95 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #96 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #97 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #98 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #99 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #100 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #101 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #102 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #103 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #104 0x555e6bf0d044 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #105 0x555e6bf0e5b2 in partial_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/_functoolsmodule.c:223:16
    #106 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #107 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #108 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #109 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #110 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #111 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #112 0x555e6bc71d53 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:52:18
    #113 0x555e6bc6e182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #114 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #115 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #116 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #117 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #118 0x555e6bdc4abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #119 0x555e6bdbf5c8 in builtin_exec_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/bltinmodule.c:1040:13
    #120 0x555e6bdbf5c8 in builtin_exec /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/clinic/bltinmodule.c.h:371:20
    #121 0x555e6bce2bf3 in cfunction_vectorcall_FASTCALL /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:427:24
    #122 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #123 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #124 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #125 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #126 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #127 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #128 0x555e6be802ac in pymain_run_module /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:293:14
    #129 0x555e6be7f6c0 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c
    #130 0x555e6be7f6c0 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #131 0x555e6be80059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #132 0x555e6be80106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #133 0x7fec1fdecb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #134 0x555e6bbce69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==348638==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==348739==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e800055243 (pc 0x7fec1ffcc702 bp 0x000000000000 sp 0x7ffc39f5d500 T348739)
==348739==The signal is caused by a READ memory access.
    #0 0x7fec1ffcc702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x555e6be87c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x555e6be87c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x555e6bce3c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x555e6bc6e182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #9 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #10 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #11 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #12 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #13 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #14 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #15 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #16 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #17 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #18 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #19 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #20 0x555e6bd1bcf4 in slot_tp_init /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7802:15
    #21 0x555e6bd07c21 in type_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:1116:19
    #22 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #23 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #24 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #25 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #26 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #27 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #28 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #29 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #30 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #31 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #32 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #33 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #34 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #35 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #36 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #37 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #38 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #39 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #40 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #41 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #42 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #43 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #44 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #45 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #46 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #47 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #48 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #49 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #50 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #51 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #52 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #53 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #54 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #55 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #56 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #57 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #58 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #59 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #60 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #61 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #62 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #63 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #64 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #65 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #66 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #67 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #68 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #69 0x555e6bc71e23 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:82:18
    #70 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #71 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #72 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #73 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #74 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #75 0x555e6bc6d5f9 in _PyObject_FastCallDictTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:141:15
    #76 0x555e6bc6ecb8 in _PyObject_Call_Prepend /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:481:24
    #77 0x555e6bd1a505 in slot_tp_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:7571:15
    #78 0x555e6bc6d93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #79 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #80 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #81 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #82 0x555e6bf0d044 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #83 0x555e6bf0e5b2 in partial_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/_functoolsmodule.c:223:16
    #84 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #85 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #86 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #87 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #88 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #89 0x555e6bc73034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #90 0x555e6bc71d53 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:52:18
    #91 0x555e6bc6e182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #92 0x555e6bdd5695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #93 0x555e6bdd5695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #94 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #95 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #96 0x555e6bdc4abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #97 0x555e6bdbf5c8 in builtin_exec_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/bltinmodule.c:1040:13
    #98 0x555e6bdbf5c8 in builtin_exec /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/clinic/bltinmodule.c.h:371:20
    #99 0x555e6bce2bf3 in cfunction_vectorcall_FASTCALL /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:427:24
    #100 0x555e6bc6e398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #101 0x555e6bc6e398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #102 0x555e6bdd2729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #103 0x555e6bdc4cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #104 0x555e6bdc4cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #105 0x555e6bc6e228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #106 0x555e6be802ac in pymain_run_module /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:293:14
    #107 0x555e6be7f6c0 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c
    #108 0x555e6be7f6c0 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #109 0x555e6be80059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #110 0x555e6be80106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #111 0x7fec1fdecb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #112 0x555e6bbce69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==348739==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==349296==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e800055470 (pc 0x7f875fbba702 bp 0x000000000000 sp 0x7fffbda60ea0 T349296)
==349296==The signal is caused by a READ memory access.
    #0 0x7f875fbba702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x55affa668c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x55affa668c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x55affa4c4c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x55affa44e93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x55affa5b3729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x55affa44f228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #9 0x7f875f0fba2d in load_reduce /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:6761:15
    #10 0x7f875f0fba2d in load /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:6909:9
    #11 0x7f875f0f13b7 in _pickle_loads_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:7861:14
    #12 0x7f875f0f13b7 in _pickle_loads /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/clinic/_pickle.c.h:834:20
    #13 0x55affa4c3d27 in cfunction_vectorcall_FASTCALL_KEYWORDS /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:443:24
    #14 0x55affa44f398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #15 0x55affa44f398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #16 0x55affa5b3729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #17 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #18 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #19 0x55affa44f228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #20 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #21 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #22 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #23 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #24 0x55affa44f182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #25 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #26 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #27 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #28 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #29 0x55affa5a5abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #30 0x55affa63328a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #31 0x55affa630527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #32 0x55affa630527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #33 0x55affa63041e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #34 0x55affa660505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #35 0x55affa660505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #36 0x55affa660505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #37 0x55affa661059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #38 0x55affa661106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #39 0x7f875f9dab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #40 0x55affa3af69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==349296==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==349308==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e80005547c (pc 0x7f875fbba702 bp 0x000000000000 sp 0x7fffbda61060 T349308)
==349308==The signal is caused by a READ memory access.
    #0 0x7f875fbba702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x55affa668c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x55affa668c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x55affa4c4c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x55affa44e93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x55affa5b3729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x55affa44f228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #9 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #10 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #11 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #12 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #13 0x55affa44f228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #14 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #15 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #16 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #17 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #18 0x55affa44f182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #19 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #20 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #21 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #22 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #23 0x55affa5a5abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #24 0x55affa63328a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #25 0x55affa630527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #26 0x55affa630527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #27 0x55affa63041e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #28 0x55affa660505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #29 0x55affa660505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #30 0x55affa660505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #31 0x55affa661059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #32 0x55affa661106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #33 0x7f875f9dab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #34 0x55affa3af69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==349308==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==349325==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e80005548d (pc 0x7f875fbba702 bp 0x000000000000 sp 0x7fffbda60be0 T349325)
==349325==The signal is caused by a READ memory access.
    #0 0x7f875fbba702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x55affa668c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x55affa668c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x55affa4c4c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x55affa44e93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x55affa5b3729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x55affa454034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #9 0x55affa452d90 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:60:20
    #10 0x55affa4f23c3 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #11 0x55affa4f576d in _PyObject_CallNoArgs /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:107:12
    #12 0x55affa4f576d in object___reduce_ex___impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:5421:19
    #13 0x55affa4c4136 in cfunction_vectorcall_O /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:513:24
    #14 0x55affa44f7b3 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #15 0x55affa44f7b3 in PyObject_CallOneArg /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:375:12
    #16 0x7f875f0f307c in _Pickle_FastCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:374:14
    #17 0x7f875f0f307c in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4419:32
    #18 0x7f875f0f4720 in batch_dict_exact /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:3279:17
    #19 0x7f875f0f4720 in save_dict /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:3333:22
    #20 0x7f875f0f2d72 in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4311:18
    #21 0x7f875f0f7426 in save_reduce /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4217:17
    #22 0x7f875f0f2f8a in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4456:14
    #23 0x7f875f0f1d8a in dump /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4502:9
    #24 0x7f875f10337f in _pickle_Pickler_dump /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4573:9
    #25 0x55affa46080e in method_vectorcall_O /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/descrobject.c:458:24
    #26 0x55affa44f398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #27 0x55affa44f398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #28 0x55affa5b3729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #29 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #30 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #31 0x55affa44f228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #32 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #33 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #34 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #35 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #36 0x55affa44f182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #37 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #38 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #39 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #40 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #41 0x55affa5a5abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #42 0x55affa63328a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #43 0x55affa630527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #44 0x55affa630527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #45 0x55affa63041e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #46 0x55affa660505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #47 0x55affa660505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #48 0x55affa660505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #49 0x55affa661059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #50 0x55affa661106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #51 0x7f875f9dab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #52 0x55affa3af69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==349325==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==349442==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e800055502 (pc 0x7f875fbba702 bp 0x000000000000 sp 0x7fffbda61060 T349442)
==349442==The signal is caused by a READ memory access.
    #0 0x7f875fbba702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x55affa668c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x55affa668c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x55affa4c4c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x55affa44e93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x55affa5b3729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x55affa44f182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #9 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #10 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #11 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #12 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #13 0x55affa44f228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #14 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #15 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #16 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #17 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #18 0x55affa44f182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #19 0x55affa5b6695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #20 0x55affa5b6695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #21 0x55affa5a5cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #22 0x55affa5a5cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #23 0x55affa5a5abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #24 0x55affa63328a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #25 0x55affa630527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #26 0x55affa630527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #27 0x55affa63041e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #28 0x55affa660505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #29 0x55affa660505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #30 0x55affa660505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #31 0x55affa661059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #32 0x55affa661106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #33 0x7f875f9dab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #34 0x55affa3af69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==349442==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==350038==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e800055756 (pc 0x7f7c80aee702 bp 0x000000000000 sp 0x7ffea76dfc30 T350038)
==350038==The signal is caused by a READ memory access.
    #0 0x7f7c80aee702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x562c9f93dc4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x562c9f93dc4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x562c9f799c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x562c9f72393a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x562c9f888729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x562c9f87acb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x562c9f87acb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x562c9f724228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #9 0x7f7c80836a2d in load_reduce /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:6761:15
    #10 0x7f7c80836a2d in load /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:6909:9
    #11 0x7f7c8082c3b7 in _pickle_loads_impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:7861:14
    #12 0x7f7c8082c3b7 in _pickle_loads /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/clinic/_pickle.c.h:834:20
    #13 0x562c9f798d27 in cfunction_vectorcall_FASTCALL_KEYWORDS /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:443:24
    #14 0x562c9f724398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #15 0x562c9f724398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #16 0x562c9f888729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #17 0x562c9f87acb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #18 0x562c9f87acb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #19 0x562c9f724228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #20 0x562c9f88b695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #21 0x562c9f88b695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #22 0x562c9f87acb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #23 0x562c9f87acb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #24 0x562c9f87aabd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #25 0x562c9f90828a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #26 0x562c9f905527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #27 0x562c9f905527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #28 0x562c9f90541e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #29 0x562c9f935505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #30 0x562c9f935505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #31 0x562c9f935505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #32 0x562c9f936059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #33 0x562c9f936106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #34 0x7f7c8090eb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #35 0x562c9f68469d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==350038==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==350049==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e800055761 (pc 0x7f27fd82f702 bp 0x000000000000 sp 0x7ffcfd641190 T350049)
==350049==The signal is caused by a READ memory access.
    #0 0x7f27fd82f702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x55a565d49c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x55a565d49c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x55a565ba5c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x55a565b2f93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x55a565c94729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x55a565c86cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x55a565c86cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x55a565b30228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #9 0x55a565c97695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #10 0x55a565c97695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #11 0x55a565c86cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #12 0x55a565c86cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #13 0x55a565b30228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #14 0x55a565c97695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #15 0x55a565c97695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #16 0x55a565c86cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #17 0x55a565c86cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #18 0x55a565c86abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #19 0x55a565d1428a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #20 0x55a565d11527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #21 0x55a565d11527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #22 0x55a565d1141e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #23 0x55a565d41505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #24 0x55a565d41505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #25 0x55a565d41505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #26 0x55a565d42059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #27 0x55a565d42106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #28 0x7f27fd64fb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #29 0x55a565a9069d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==350049==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==350060==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e80005576c (pc 0x7fe3d4be5702 bp 0x000000000000 sp 0x7ffe92fe2230 T350060)
==350060==The signal is caused by a READ memory access.
    #0 0x7fe3d4be5702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x55d6a924fc4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x55d6a924fc4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x55d6a90abc09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x55d6a903593a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x55d6a919a729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x55d6a918ccb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x55d6a918ccb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x55d6a903b034 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #9 0x55d6a9039d90 in method_vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/classobject.c:60:20
    #10 0x55d6a90d93c3 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #11 0x55d6a90dc76d in _PyObject_CallNoArgs /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:107:12
    #12 0x55d6a90dc76d in object___reduce_ex___impl /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/typeobject.c:5421:19
    #13 0x55d6a90ab136 in cfunction_vectorcall_O /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:513:24
    #14 0x55d6a90367b3 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #15 0x55d6a90367b3 in PyObject_CallOneArg /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:375:12
    #16 0x7fe3d492507c in _Pickle_FastCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:374:14
    #17 0x7fe3d492507c in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4419:32
    #18 0x7fe3d4926720 in batch_dict_exact /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:3279:17
    #19 0x7fe3d4926720 in save_dict /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:3333:22
    #20 0x7fe3d4924d72 in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4311:18
    #21 0x7fe3d4929426 in save_reduce /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4217:17
    #22 0x7fe3d4924f8a in save /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4456:14
    #23 0x7fe3d4923d8a in dump /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4502:9
    #24 0x7fe3d493537f in _pickle_Pickler_dump /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/_pickle.c:4573:9
    #25 0x55d6a904780e in method_vectorcall_O /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/descrobject.c:458:24
    #26 0x55d6a9036398 in _PyObject_VectorcallTstate /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_call.h:92:11
    #27 0x55d6a9036398 in PyObject_Vectorcall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:298:12
    #28 0x55d6a919a729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #29 0x55d6a918ccb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #30 0x55d6a918ccb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #31 0x55d6a9036228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #32 0x55d6a919d695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #33 0x55d6a919d695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #34 0x55d6a918ccb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #35 0x55d6a918ccb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #36 0x55d6a918cabd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #37 0x55d6a921a28a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #38 0x55d6a9217527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #39 0x55d6a9217527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #40 0x55d6a921741e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #41 0x55d6a9247505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #42 0x55d6a9247505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #43 0x55d6a9247505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #44 0x55d6a9248059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #45 0x55d6a9248106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #46 0x7fe3d4a05b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #47 0x55d6a8f9669d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==350060==ABORTING
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==350176==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x03e8000557e0 (pc 0x7f7958e59702 bp 0x000000000000 sp 0x7fff04e21290 T350176)
==350176==The signal is caused by a READ memory access.
    #0 0x7f7958e59702 in raise (/usr/lib/libpthread.so.0+0x13702)
    #1 0x5624a3fd5c4d in faulthandler_raise_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1065:5
    #2 0x5624a3fd5c4d in faulthandler_sigsegv /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Modules/faulthandler.c:1081:9
    #3 0x5624a3e31c09 in cfunction_call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/methodobject.c:549:18
    #4 0x5624a3dbb93a in _PyObject_MakeTpCall /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:214:18
    #5 0x5624a3f20729 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c
    #6 0x5624a3f12cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #7 0x5624a3f12cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #8 0x5624a3dbc182 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:256:24
    #9 0x5624a3f23695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #10 0x5624a3f23695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #11 0x5624a3f12cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #12 0x5624a3f12cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #13 0x5624a3dbc228 in _PyVectorcall_Call /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Objects/call.c:244:16
    #14 0x5624a3f23695 in do_call_core /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:7142:12
    #15 0x5624a3f23695 in _PyEval_EvalFrameDefault /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:5220:22
    #16 0x5624a3f12cb1 in _PyEval_EvalFrame /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/./Include/internal/pycore_ceval.h:53:16
    #17 0x5624a3f12cb1 in _PyEval_Vector /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:6252:24
    #18 0x5624a3f12abd in PyEval_EvalCode /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/ceval.c:1101:21
    #19 0x5624a3fa028a in run_eval_code_obj /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1680:9
    #20 0x5624a3f9d527 in run_mod /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1701:19
    #21 0x5624a3f9d527 in PyRun_StringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:1571:15
    #22 0x5624a3f9d41e in PyRun_SimpleStringFlags /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Python/pythonrun.c:487:9
    #23 0x5624a3fcd505 in pymain_run_command /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:248:11
    #24 0x5624a3fcd505 in pymain_run_python /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:583:21
    #25 0x5624a3fcd505 in Py_RunMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:671:5
    #26 0x5624a3fce059 in pymain_main /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:701:12
    #27 0x5624a3fce106 in Py_BytesMain /buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/Modules/main.c:725:12
    #28 0x7f7958c79b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #29 0x5624a3d1c69d in _start (/buildbot/buildarea/3.x.pablogsal-arch-x86_64.clang-ubsan/build/python+0x2f469d)

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV (/usr/lib/libpthread.so.0+0x13702) in raise
==350176==ABORTING

----------
components: Tests
messages: 414901
nosy: gregory.p.smith, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures logs many UndefinedBehaviorSanitizer "DEADLYSIGNAL" errors on AMD64 Arch Linux Usan 3.x
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 11 08:30:32 2022
From: report at bugs.python.org (Pradyun Gedam)
Date: Fri, 11 Mar 2022 13:30:32 +0000
Subject: [New-bugs-announce] [issue46985] Upgrade bundled pip to 22.0.4
Message-ID: <1647005432.9.0.668386387215.issue46985@roundup.psfhosted.org>


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

Looks like I forgot to file PRs for the last few pip releases. :)

----------
components: Library (Lib)
messages: 414904
nosy: pradyunsg
priority: normal
severity: normal
status: open
title: Upgrade bundled pip to 22.0.4
type: enhancement
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/issue46985>
_______________________________________

From report at bugs.python.org  Fri Mar 11 08:47:45 2022
From: report at bugs.python.org (Pradyun Gedam)
Date: Fri, 11 Mar 2022 13:47:45 +0000
Subject: [New-bugs-announce] [issue46986] Upgrade ensurepip bundled
 setuptools to 60.9.3
Message-ID: <1647006465.36.0.073605933611.issue46986@roundup.psfhosted.org>


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

This is closely related to bpo-46985.

I'm changing up the regular strategy of a single PR that bumps both pip + setuptools in a single PR. So... here's a separate bpo issue for that.

----------
components: Library (Lib)
messages: 414906
nosy: pradyunsg
priority: normal
severity: normal
status: open
title: Upgrade ensurepip bundled setuptools to 60.9.3
type: enhancement
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/issue46986>
_______________________________________

From report at bugs.python.org  Fri Mar 11 09:08:22 2022
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 11 Mar 2022 14:08:22 +0000
Subject: [New-bugs-announce] [issue46987] Remove _PySys_GetObjectId /
 _PySys_GetObjectId
Message-ID: <1647007702.33.0.743675415066.issue46987@roundup.psfhosted.org>


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

There is no usage of _PySys_GetObjectId / _PySys_GetObjectId private APIs in CPython project.
Since these APIs use _Py_Identifier as the parameter, it looks good to be removed this time when there is no usage at all.
But before removing these APIs, I will investigate the current usage of external projects even if they are not intended to be used from outside.

----------
assignee: corona10
components: C API
messages: 414907
nosy: corona10, eric.snow, vstinner
priority: normal
severity: normal
status: open
title: Remove _PySys_GetObjectId / _PySys_GetObjectId
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 11 11:41:05 2022
From: report at bugs.python.org (markhuang3310)
Date: Fri, 11 Mar 2022 16:41:05 +0000
Subject: [New-bugs-announce] [issue46988] if a python program is execute by
 subprocess,
 the python program can't output unicode characters and raise
 UnicodeEncodeError
Message-ID: <1647016865.89.0.743756251929.issue46988@roundup.psfhosted.org>


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

Env:
Windows 10
Python3.8.10 amd64

Desciption:

I try to get output from a python program with a subprocess.
The python program print a unicode character.

```
import subprocess
import sys
cmd = rf'''{sys.executable} -c "print('\u042f')"'''

print('case 1')
stdout, stderr =  subprocess.Popen(cmd, stderr=subprocess.PIPE, stdout=None).communicate()
print('case 2')
stdout, stderr =  subprocess.Popen(cmd, stderr=subprocess.PIPE, stdout=subprocess.PIPE).communicate()
print(stderr)
```

The issue is that:
In case 1, I can see the "?" (\u042f) form console.
In case 2, I try to get the output from subprocess.Popen(command).communicate()[0], the python process fail with   UnicodeEncodeError.

Expected result:
In case2, I should get stdout == b'\u042f'

----------
components: Windows
files: test.py
messages: 414919
nosy: markhuang3310, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: if a python program is execute by subprocess, the python program  can't output unicode characters and raise UnicodeEncodeError
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50667/test.py

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

From report at bugs.python.org  Fri Mar 11 14:12:02 2022
From: report at bugs.python.org (Enji Cooper)
Date: Fri, 11 Mar 2022 19:12:02 +0000
Subject: [New-bugs-announce] [issue46989] signal.signal, et al,
 doesn't support [SIGRTMIN, SIGRTMAX] on FreeBSD (not included in NSIG)
Message-ID: <1647025922.75.0.622565693029.issue46989@roundup.psfhosted.org>


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

As noted in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262487, cpython relies on the definition of NSIG when building signal handlers to determine what signals are and aren't invalid.

Unfortunately on FreeBSD, NSIG doesn't include [SIGRTMIN,SIGRTMAX], as shown below:

$ python2
Python 2.7.18 (default, Dec  3 2020, 01:19:40) 
[GCC 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.signal(signal.SIGRTMIN, signal.SIG_DFL)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: signal number out of range
>>> exit()
$ python3
Python 3.8.12 (default, Jan  4 2022, 01:10:15) 
[Clang 10.0.1 (git at github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611a on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.signal(signal.SIGRTMIN, signal.SIG_IGN)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal number out of range
>>> exit()
$ python3.11
Python 3.11.0a3 (main, Feb  4 2022, 02:34:52) [Clang 10.0.1 (git at github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.signal(signal.SIGRTMIN, signal.SIG_IGN)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: signal number out of range
>>> exit()
$

This results in a cpython interface which doesn't match the OS's signal(3) interface:

```
$ cat signal_rtmin.c 
#include <err.h>
#include <signal.h>

int     
main(void)      
{       

        if (signal(SIGRTMIN, SIG_DFL) == SIG_ERR)
                warn("signal");
        return (0);
}
$ cc -o signal_rtmin -Wall signal_rtmin.c
$ ./signal_rtmin
$ uname -a
FreeBSD picasso.local 12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC  amd64
$
```

Linux includes [SIGRTMIN,SIGRTMAX] in NSIG, which means it allows these values in signal.signal without issue (confirmed on Ubuntu 18.04.6 LTS).

While one can definitely argue that this is an OS portability defect and this should be resolved in FreeBSD (and thus, not fixed in cpython), it doesn't address existing behavior on older versions of FreeBSD where this hasn't been resolved yet.

FreeBSD bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262487

----------
components: FreeBSD
messages: 414932
nosy: koobs, ngie
priority: normal
severity: normal
status: open
title: signal.signal, et al, doesn't support [SIGRTMIN,SIGRTMAX] on FreeBSD (not included in NSIG)
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/issue46989>
_______________________________________

From report at bugs.python.org  Fri Mar 11 17:37:20 2022
From: report at bugs.python.org (Tim Peters)
Date: Fri, 11 Mar 2022 22:37:20 +0000
Subject: [New-bugs-announce] [issue46990] Surprising list overallocation
 from .split()
Message-ID: <1647038240.05.0.997478605012.issue46990@roundup.psfhosted.org>


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

When looking into a StackOverflow question about surprisingly high memory use, I stumbled into this (under 3.10.1, Win64):

>>> import sys
>>> s = "1 2 3 4 5".split()
>>> s
['1', '2', '3', '4', '5']
>>> sys.getsizeof(s)
152
>>> _ - sys.getsizeof([])
96
>>> 96 / 8
12.0

That is, we allocated enough space in the list to store 12(!) elements, despite that only 5 are used. Other ways of building a 5-element list I've tried overallocate by at most 3 slots:

>>> sys.getsizeof([ch for ch in "12345"])
120
>>> sys.getsizeof([1, 2, 3, 4, 5])
120

(and 120 - 56 = 64, room for 8 pointers)

Then there's this curiosity, which allocates space for exactly the 5 needed:

>>> sys.getsizeof(list(tuple("1 2 3 4 5".split())))
96

(and 96 - 56 = 40, room for the 5 pointers needed)

I don't expect this to be consistent, but allocating space for 12 when only 5 are needed is unreasonable. Even allocating space for 8 is pushing it ;-)

----------
components: Interpreter Core
messages: 414942
nosy: tim.peters
priority: normal
severity: normal
status: open
title: Surprising list overallocation from .split()
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 11 23:07:28 2022
From: report at bugs.python.org (Ken Jin)
Date: Sat, 12 Mar 2022 04:07:28 +0000
Subject: [New-bugs-announce] [issue46991] Specialize list[slice]
Message-ID: <1647058048.98.0.646431453049.issue46991@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

According to https://github.com/faster-cpython/ideas/blob/main/stats.md#binary_subscr
it's the second most common failed specialization.

array.array[int] is quite hard to specialize, considering that array.array deals with 13 different item types based on its initial type argument. IMO specializing for it is only useful to bump benchmark numbers, but we won't see any real effects in real-world benchmarks.

----------
messages: 414971
nosy: kj
priority: normal
severity: normal
status: open
title: Specialize list[slice]
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 12 00:01:38 2022
From: report at bugs.python.org (=?utf-8?b?6rmA7KSA7ZmY?=)
Date: Sat, 12 Mar 2022 05:01:38 +0000
Subject: [New-bugs-announce] [issue46992] If use textwrap.dedent with string
 formatting, may get unintended sentences.
Message-ID: <1647061298.28.0.525583998057.issue46992@roundup.psfhosted.org>


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

If use textwrap.dedent with string formatting, may get unintended sentences.

For example, a sentence like this:

```
import textwrap

def get_something_string():
    return textwrap.dedent("""\
        test text2
        test text3
        test text4""")

textwrap.dedent(f"""\
    test text1
    {get_something_string()}
    test text5
    test text6""")
```

I look forward to the following results.

```
test text1
test text2
test text3
test text4
test text5
test text6
```

But the actual result is:
```
    test text1
    test text2
test text3
test text4
    test text5
    test text6
```

I understand that this code works in this way because the intent of the string defined inside the method is different from the intent of the string outside the method.

However, regular users, like me, will think of having a consistent intent result value. (because they believe dedent will clear a consistent intent)

If you are concerned that the existing code will be broken, I can implement the function using the flag parameter.

If you agree with my opinion, I will submit a PR.

----------
components: Library (Lib)
messages: 414972
nosy: xncbf12
priority: normal
severity: normal
status: open
title: If use textwrap.dedent with string formatting, may get unintended sentences.
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Mar 12 04:40:17 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 12 Mar 2022 09:40:17 +0000
Subject: [New-bugs-announce] [issue46993] Speed up bytearray creation from
 list and tuple
Message-ID: <1647078017.1.0.00491619232852.issue46993@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

The attached PR speeds up bytearray creation from list and tuple.

Benchmark (uses pyperf):
-----------------------------------------------------
import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench bytearray",
              stmt="bytearray([42]*10000)",)
-----------------------------------------------------

Results:

-----------------------------------------------------
Mean +- std dev: [base] 74.8 us +- 5.5 us -> [patch] 53.2 us +- 3.3 us: 1.41x faster
-----------------------------------------------------

----------
components: Interpreter Core
messages: 414987
nosy: gvanrossum, kumaraditya303
priority: normal
pull_requests: 29935
severity: normal
status: open
title: Speed up bytearray creation from list and tuple
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 12 05:33:08 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 12 Mar 2022 10:33:08 +0000
Subject: [New-bugs-announce] [issue46994] Accept explicit
 contextvars.Context in asyncio create_task() API
Message-ID: <1647081188.22.0.709370904314.issue46994@roundup.psfhosted.org>


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

Now asyncio creates a new context copy on task creation.

It is the perfect behavior *by default* and should stay as is.

However, sometimes passing an explicit context into a task and using back the context modified by task code is desired.

The most obvious use-case is testing: both unittest and pytest have multi-phase test initialization (asyncSetUp() methods and async fixtures correspondingly).  If asyncSetUp() updates context variable -- test code expects to see this change.

Currently, unittest runs the setup-test-cleanup chain in a single task and uses an internal queue to push a new coroutine for execution and get results back. It works but is cumbersome.

Another solution is to create a task per test execution step and wrap the task creation with Context.run(). The problem is in getting the updated context back. A task creates a context copy on starting, thus the modified context is stored in the task internal attribute only. To get it back a trampoline async function should be used, e.g.

async def wrapper(coro):
    try:
        return await coro
    finally:
        context = contextvars.copy_context()
        # store the context copy somewhere

Again, it looks more complicated as it should be.

The proposal is: 
1. Add 'context' keyword-only argument to asyncio.create_task() and loop.create_task().
2. Use this context if explicitly passed, create a copy of the current context otherwise.

The proposal is backward-compatible. Low-level API (call_soon(), call_later() etc.) already accept 'context' argument.

The attached PR demonstrates how the proposed API simplifies unittest.IsolatedAsyncioTestCase internals.

----------
components: asyncio
messages: 414988
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Accept explicit contextvars.Context in asyncio create_task() API
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 12 06:48:31 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 12 Mar 2022 11:48:31 +0000
Subject: [New-bugs-announce] [issue46995] Make Task.set_name() mandatory for
 third-parties
Message-ID: <1647085711.65.0.890439672207.issue46995@roundup.psfhosted.org>


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

The method was introduced by Python 3.8

Let's raise DeprecationWarning if third-party task implementation doesn't support it. Convert the depreciation into a strict error in Python 3.13

----------
components: asyncio
messages: 414990
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Make Task.set_name() mandatory for third-parties
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 12 11:03:38 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Mar 2022 16:03:38 +0000
Subject: [New-bugs-announce] [issue46996] Drop support of Tcl/Tk older than
 8.5.12
Message-ID: <1647101018.44.0.57860605779.issue46996@roundup.psfhosted.org>


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

In issue45979 E. Paine suggested to drop support of Tcl/Tk older than 8.5.12 (8.5.12 was released on 2012-07-27 and 8.6.0 on 2012-12-20). Tkinter tests contain workarounds and special cases for older versions of Tcl/Tk, many of them can be removed. Also some Python and C code of tkinter can be simplified.

----------
components: Library (Lib), Tests
messages: 414999
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Drop support of Tcl/Tk older than 8.5.12
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 12 21:05:03 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 13 Mar 2022 02:05:03 +0000
Subject: [New-bugs-announce] [issue46997] Invalid memory write in bytearray
Message-ID: <1647137103.05.0.520249500347.issue46997@roundup.psfhosted.org>


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

Inspired by Guido's comment in https://github.com/python/cpython/pull/31834/files#r825352900, I found that there are some places in bytearrayobject.c where we can write to free'd memory if we encounter an object with a sneaky __index__ method:

$ cat basneak.py 
ba = bytearray([0 for _ in range(10000)])

class sneaky:
    def __index__(self):
        ba.clear()
        return 1

ba[-1] = sneaky()
$ valgrind ./python basneak.py 
==87894== Memcheck, a memory error detector
==87894== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==87894== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==87894== Command: ./python basneak.py
==87894== 
==87894== Invalid write of size 1
==87894==    at 0x49B70F: bytearray_ass_subscript (bytearrayobject.c:632)
==87894==    by 0x488E03: PyObject_SetItem (abstract.c:211)
<snip>

In bytearray_setitem(), we first do bounds checking, and then call _getbytevalue() to get the numeric value of the argument.

I think there's a similar bug in bytearray_ass_subscript().

----------
messages: 415021
nosy: JelleZijlstra, gvanrossum
priority: normal
severity: normal
status: open
title: Invalid memory write in bytearray

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

From report at bugs.python.org  Sat Mar 12 22:06:37 2022
From: report at bugs.python.org (Shantanu)
Date: Sun, 13 Mar 2022 03:06:37 +0000
Subject: [New-bugs-announce] [issue46998] Allow subclassing Any at runtime
Message-ID: <1647140797.69.0.86032805072.issue46998@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

Discussed on typing-sig at https://mail.python.org/archives/list/typing-sig at python.org/thread/GULRKYI7XOB3FLAEFC6OYSTBS5FIA5PU/

----------
components: Library (Lib)
messages: 415023
nosy: JelleZijlstra, hauntsaninja
priority: normal
severity: normal
status: open
title: Allow subclassing Any at runtime
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 13 00:17:57 2022
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 13 Mar 2022 05:17:57 +0000
Subject: [New-bugs-announce] [issue46999] test_multiprocessing_fork running
 without any timeout
Message-ID: <1647148677.24.0.613958447679.issue46999@roundup.psfhosted.org>


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

the test_multiprocessing_fork test is a bit unreliable, at least on both the Debian and Ubuntu test infrastructures, sometimes running for 100+ hours.  When running locally, I cannot reproduce these issues.  Note that the test and build infrastructure is usually limited to 4-6 cores and 20GB of RAM (including swap). What else could be an issue for these hangs?

How can this test reliably timeout?  I know it takes a few hours on slow architectures even when succeeding.

----------
components: Tests
messages: 415027
nosy: doko
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork running without any timeout

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

From report at bugs.python.org  Sun Mar 13 01:09:52 2022
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 13 Mar 2022 06:09:52 +0000
Subject: [New-bugs-announce] [issue47000] Make encoding="locale" uses locale
 encoding even in UTF-8 mode is enabled.
Message-ID: <1647151792.05.0.892379342783.issue47000@roundup.psfhosted.org>


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

Currently, `encoding="locale"` is just shortcut of `encoding=locale.getpreferredencoding(False)`.

`encoding="locale"` means that "locale encoding should be used here, even if Python default encoding is changed to UTF-8".

I am not sure that UTF-8 mode becomes the default or not.
But some user want to use UTF-8 mode to change default encoding in their Python environments without waiting Python default encoding changed.

So I think `encoding="locale"` should use real locale encoding (ACP on Windows) regardless UTF-8 mode is enabled or not.

Currently, UTF-8 mode affects to `_Py_GetLocaleEncoding()`. So it is difficult that make encoding="locale" ignores UTF-8 mode.
Is it safe to use `locale.getlocale(locale.LC_CTYPE)[1] or "UTF-8"`?

----------
components: Unicode
messages: 415028
nosy: ezio.melotti, methane, vstinner
priority: normal
severity: normal
status: open
title: Make encoding="locale" uses locale encoding even in UTF-8 mode is enabled.
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 13 01:43:48 2022
From: report at bugs.python.org (Rocco Matano)
Date: Sun, 13 Mar 2022 06:43:48 +0000
Subject: [New-bugs-announce] [issue47001] deadlock in ctypes?
Message-ID: <1647153828.18.0.33672344904.issue47001@roundup.psfhosted.org>


New submission from Rocco Matano <rocco.matano at web.de>:

When using ctypes under Windows, I have observed a baffling behavior which I am not sure if it is the result of a bug in ctypes, or is simply due to false expectations on my part.

Environment:
 - Windows 10 Pro, 21H1, 19043.1586, x64
 - Python versions 3.6 up to 3.10, x64
 
What I was trying to do was to enumerate all the icons in the resource section of an executable file. The Windows-API for such a case is EnumResourceNamesW, which requires the pointer to a callback function as an argument. I wanted to hide the details of the corresponding code so that a user of that code does not have to deal with ctypes directly and can supply a regular Python function for the callback. So I added an extra level of indirection.

When I ran my code, I was surprised to observe that the program was stuck. After several tries, I found a solution that differed from the original code only in one small detail: Use different types when describing the C callback.

Below is a self contained sample that can be used to show the successful case as well as to trigger the blocking. Unfortunately it is quit long. 


import sys
import ctypes
from ctypes.wintypes import HMODULE, LPVOID, LPWSTR, BOOL

# context structure that is used to use regular python functions as callbacks
# where external C code expects C callbacks with a certain signature.
class CallbackContext(ctypes.Structure):
    _fields_ = (
        ("callback", ctypes.py_object),
        ("context", ctypes.py_object),
        )

CallbackContextPtr = ctypes.POINTER(CallbackContext)

# quote from
# https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nc-libloaderapi-enumresnameprocw
#
# BOOL Enumresnameprocw(
#   [in, optional] HMODULE hModule,
#                  LPCWSTR lpType,
#                  LPWSTR lpName,
#   [in]           LONG_PTR lParam
# )
# Note that the arguments lpType and lpName are declared as pointers to strings.


if len(sys.argv) > 1 and sys.argv[1].lower() == "fail":
    # Declaring them as pointers to strings in the ctypes prototype does NOT work.
    EnumResNameCallback_prototype = ctypes.WINFUNCTYPE(
        BOOL,
        HMODULE,
        LPWSTR,
        LPWSTR,
        CallbackContextPtr
        )
else:
    # Declaring them as void pointers does work!
    EnumResNameCallback_prototype = ctypes.WINFUNCTYPE(
        BOOL,
        HMODULE,
        LPVOID,
        LPVOID,
        CallbackContextPtr
        )

# this is the ctypes callback function that mimics the required C call signature
@EnumResNameCallback_prototype
def EnumResNameCallback(hmod, typ, name, ctxt):
    cbc = ctxt.contents
    return cbc.callback(hmod, typ, name, cbc.context)

kernel32 = ctypes.windll.kernel32

EnumResourceNames = kernel32.EnumResourceNamesW
EnumResourceNames.restype = BOOL
EnumResourceNames.argtypes = (
    HMODULE,
    LPWSTR,
    EnumResNameCallback_prototype,
    CallbackContextPtr
    )

# Get a module handle for an executable that contains icons
GetModuleHandle = kernel32.GetModuleHandleW
GetModuleHandle.restype = HMODULE
GetModuleHandle.argtypes = (LPWSTR,)

hmod = GetModuleHandle(sys.executable)
if hmod == 0:
    raise ctypes.WinError()

RT_GROUP_ICON = ctypes.cast(14, LPWSTR)

# this is the 'regular' callback function that does not have to care about
# the C call signature
def enum_callback(hmod, typ, name, unused_context):
    print(hmod, typ, name)
    return True

cbc = CallbackContext(enum_callback, None)
rcbc = ctypes.byref(cbc)

print("Trying to enumerate icons.")
print("In the case of failure, this WILL BLOCK indefinitely!")
EnumResourceNames(hmod, RT_GROUP_ICON, EnumResNameCallback, rcbc)

----------
components: ctypes
messages: 415029
nosy: rocco.matano
priority: normal
severity: normal
status: open
title: deadlock in ctypes?
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Mar 13 04:29:17 2022
From: report at bugs.python.org (Pythass)
Date: Sun, 13 Mar 2022 08:29:17 +0000
Subject: [New-bugs-announce] [issue47002] argparse - "expected one argument"
 when used -: in argument
Message-ID: <1647160157.96.0.277366172749.issue47002@roundup.psfhosted.org>


New submission from Pythass <crazysnob at live.it>:

By using argparse, and by passing a string as argument that has both a dash "-" and colon ":", python returns "expected one argument" error, despite it works when I use only "-" without ":".

An example of code is attached at the ticket.

Examples of triggering "expected one argument" error:
python test.py -u -1:00
python test.py -u -1:

Examples of NON triggering "expected one argument" error:
python test.py -u -1
python test.py -u=-1:00

----------
components: Parser
files: test.py
messages: 415031
nosy: Pythass, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: argparse - "expected one argument" when used -: in argument
type: compile error
versions: Python 3.10
Added file: https://bugs.python.org/file50668/test.py

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

From report at bugs.python.org  Sun Mar 13 13:44:24 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 13 Mar 2022 17:44:24 +0000
Subject: [New-bugs-announce] [issue47003] Cleanup _overlapped module
Message-ID: <1647193464.85.0.127988629584.issue47003@roundup.psfhosted.org>


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

1. CancelIoEx is mandatory for supported Windows versions, there is no need for dynamic checks.
2. Argument Clinic supports Py_buffer, use it.

----------
components: asyncio
messages: 415064
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Cleanup _overlapped module
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 13 14:53:30 2022
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 13 Mar 2022 18:53:30 +0000
Subject: [New-bugs-announce] [issue47004] Apply bugfixes from
 importlib_metadata 4.11.3.
Message-ID: <1647197610.76.0.445327879408.issue47004@roundup.psfhosted.org>


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

Importlib_metadata 4.11.1-3 introduced a few bug fixes. Importantly, 4.11.2 fixed a [serious defect](https://github.com/python/importlib_metadata/issues/369). Let's incorporate those fixes into CPython.

----------
messages: 415075
nosy: jaraco
priority: normal
severity: normal
status: open
title: Apply bugfixes from importlib_metadata 4.11.3.
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Mar 13 15:01:26 2022
From: report at bugs.python.org (Pieter Eendebak)
Date: Sun, 13 Mar 2022 19:01:26 +0000
Subject: [New-bugs-announce] [issue47005] Improve performance of bytes_repeat
Message-ID: <1647198086.65.0.133480575826.issue47005@roundup.psfhosted.org>


New submission from Pieter Eendebak <pieter.eendebak at gmail.com>:

The bytearray_repeat and bytearray_irepeat are inefficient for small arrays and a high number of repeats.
This can be improved by using the same approach is in the corresponding bytes_repeat method.

Microbenchmark:

python -m pyperf timeit "b=bytearray([1,2,])*100" 

Mean +- std dev: [base100] 479 ns +- 29 ns -> [patch100] 274 ns +- 18 ns: 1.75x faster

python -m pyperf timeit "b=bytearray([1,2,])*1000"

Mean +- std dev: [base1000] 2.58 us +- 0.18 us -> [patch1000] 399 ns +- 26 ns: 6.46x faster

----------
components: Interpreter Core
messages: 415077
nosy: pieter.eendebak
priority: normal
severity: normal
status: open
title: Improve performance of bytes_repeat
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 13 16:46:16 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 13 Mar 2022 20:46:16 +0000
Subject: [New-bugs-announce] [issue47006] PEP 646: Decide on substitution
 behavior
Message-ID: <1647204376.33.0.359883240304.issue47006@roundup.psfhosted.org>


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

We've had some disagreement about the behavior of TypeVarTuple substitution related to PEP 646, and the discussion has now spilled around multiple PRs. I'd like to use this issue to come to an agreement so we don't have to chase through so many different places.

Links:
- GH-31021 (merged) implements PEP 646 in typing.py. Matthew initially implemented full TypeVar substitution support, but took it out after I suggested an alternative solution in https://github.com/python/cpython/pull/31021#pullrequestreview-890627941.
- GH-31800 (merged without review) implements TypeVarTuple substitution in Python.
- GH-31828 implements TypeVarTuple substitution in C.
- GH-31844 and GH-31846 add additional test cases.
- GH-31804 (closed) implements my proposed solution.

I'd like to ask that until we come to an agreement we hold off on making any more changes, so we don't have to go back and forth and we ensure that the eventual solution covers all edge cases.

The disagreement is about what to do with TypeVarTuple substitution: the behavior when a generic type is subscripted, like `tuple[*Ts][int, str]`.

There are two possible extreme approaches:
- Implement full substitution support, just as we have it for existing TypeVars. This is complicated because TypeVarTuple makes it much harder to match up the types correctly. However, it is consistent with the behavior for other TypeVar-like objects. My example would turn into GenericAlias(tuple, (int, str)).
- Give up on substitution and just return a new GenericAlias object: GenericAlias(GenericAlias(tuple, Unpack[Ts]), (int, str). This avoids implementing any complex runtime behavior, but it inconsistent with existing behavior and less pretty when you print out the type. I prefer this approach because there's less risk that future enhancements to typing will break it. I also want to explore extending this approach to ParamSpec substitution.

----------
assignee: JelleZijlstra
messages: 415100
nosy: JelleZijlstra, gvanrossum, kj, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP 646: Decide on substitution behavior
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 13 20:40:21 2022
From: report at bugs.python.org (Vanshaj Singhania)
Date: Mon, 14 Mar 2022 00:40:21 +0000
Subject: [New-bugs-announce] [issue47007] [doc] str docs are inconsistent
 with special method lookup
Message-ID: <1647218421.76.0.418268186673.issue47007@roundup.psfhosted.org>


New submission from Vanshaj Singhania <svanshaj2001 at gmail.com>:

The documentation for the `str` class[^1] says:

> If neither encoding nor errors is given, str(object) returns object.__str__()

This led our students[^2] to try the following code:

    >>> class Test:
    ...     def __str__(self):
    ...         return 'hi'
    ... 
    >>> test = Test()
    >>> test.__str__ = lambda self: 'bye'
    >>> str(test)

The expected result was calling `test.__str__()`, but instead the interpreter output was `'hi'`.

The docs for special method lookup[^3] do say that instance attributes are ignored:

> For custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object?s type, not in the object?s instance dictionary.

This makes sense, and explains the observed behavior, but the `str` class docs seem to be inconsistent with this. Perhaps it would be more clear if the `str` documentation mentioned that it called `type(object).__str__()` instead of `object.__str__()`.

[^1]: https://docs.python.org/3/library/stdtypes.html#str
[^2]: CS 61A at UC Berkeley, https://cs61a.org
[^3]: https://docs.python.org/3/reference/datamodel.html#special-method-lookup

----------
assignee: docs at python
components: Documentation
messages: 415110
nosy: docs at python, itsvs
priority: normal
severity: normal
status: open
title: [doc] str docs are inconsistent with special method lookup
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun Mar 13 23:21:53 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Mar 2022 03:21:53 +0000
Subject: [New-bugs-announce] [issue47008] Add Lib/site-packages to .gitignore
Message-ID: <1647228113.84.0.370767511712.issue47008@roundup.psfhosted.org>


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

It would be nice to add the following to .gitignore, so that I can `./python -m pip install [whatever]` without overwhelming the output of `git status`.

Lib/site-packages/*
!Lib/test/data/README.txt

----------
messages: 415114
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Add Lib/site-packages to .gitignore
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 14 00:57:38 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Mar 2022 04:57:38 +0000
Subject: [New-bugs-announce] [issue47009] Streamline list.append for the
 common case
Message-ID: <1647233858.4.0.304324509353.issue47009@roundup.psfhosted.org>


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

list_resize is a long function that probably won't get inlined. But for the vast majority of cases in list.append, we just need to check whether the list is big enough (not whether it's small enough, or whether it's null or the wrong type), then insert and update the size. This can be inlined, with an actual call only taking place whenever we need to resize.

We can also add a reference-consuming version of PyList_Append to elide an INCREF/DECREF pair.

----------
components: Interpreter Core
messages: 415116
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Streamline list.append for the common case
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 14 05:18:42 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 14 Mar 2022 09:18:42 +0000
Subject: [New-bugs-announce] [issue47010] Implement zero copy writes in
 SelectorSocketTransport in asyncio
Message-ID: <1647249522.0.0.992096149336.issue47010@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Currently, _SelectorSocketTransport transport creates a copy of the data before sending which in case of large amount of data, can create multiple giga bytes copies of data before sending.

Script demonstrating current behavior:

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

import asyncio
import memory_profiler

@memory_profiler.profile
async def handle_echo(reader: asyncio.StreamReader, writer: asyncio.StreamWriter):
    data = b'x' * 1024 * 1024 * 1000 # 1000 MiB payload
    writer.write(data)
    await writer.drain()
    writer.close()

async def main():
    server = await asyncio.start_server(
        handle_echo, '127.0.0.1', 8888)

    addrs = ', '.join(str(sock.getsockname()) for sock in server.sockets)
    print(f'Serving on {addrs}')

    async with server:
        asyncio.create_task(server.start_serving())
        reader, writer = await asyncio.open_connection('127.0.0.1', 8888)
        while True:
            data = await reader.read(1024 * 1024 * 100)
            if not data:
                break

asyncio.run(main())
-------------------------------------------------------------------------

Memory profile result:
------------------------------------------------------------------------
Filename: test.py

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
     4     17.7 MiB     17.7 MiB           1   @memory_profiler.profile
     5                                         async def handle_echo(reader: asyncio.StreamReader, writer: asyncio.StreamWriter):
     6   1017.8 MiB   1000.1 MiB           1       data = b'x' * 1024 * 1024 * 1000 # 1000 MiB payload
     7   2015.3 MiB    997.5 MiB           1       writer.write(data)
     8   2015.3 MiB   -988.1 MiB           2       await writer.drain()
     9   1027.1 MiB   -988.1 MiB           1       writer.close()

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

To make it zero copy, python's buffer protocol can be used and use memory views of data to save RAM. The writelines method currently joins all the data before sending whereas it can use `socket.sendmsg` to make it more memory efficient.


Links:

- writelines - https://github.com/python/cpython/blob/2153daf0a02a598ed5df93f2f224c1ab2a2cca0d/Lib/asyncio/transports.py#L116

- socket.sendmsg - https://docs.python.org/3/library/socket.html#socket.socket.sendmsg

- memory_profiler -
https://pypi.org/project/memory-profiler/

----------
components: asyncio
messages: 415124
nosy: asvetlov, gvanrossum, kumaraditya303, yselivanov
priority: normal
severity: normal
status: open
title: Implement zero copy writes in SelectorSocketTransport in asyncio
type: resource usage
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 14 06:25:59 2022
From: report at bugs.python.org (Learn Coding)
Date: Mon, 14 Mar 2022 10:25:59 +0000
Subject: [New-bugs-announce] [issue47011] Cloned turtle pen is not cleared
 completely
Message-ID: <1647253559.7.0.0341872922214.issue47011@roundup.psfhosted.org>


New submission from Learn Coding <ngogiaquy3 at gmail.com>:

When calling clear() method on a cloned turtle, some painted lines still remain on the screen.

----------
components: Library (Lib)
files: testturtle.py
messages: 415125
nosy: learncoding
priority: normal
severity: normal
status: open
title: Cloned turtle pen is not cleared completely
versions: Python 3.10
Added file: https://bugs.python.org/file50673/testturtle.py

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

From report at bugs.python.org  Mon Mar 14 07:13:25 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Mon, 14 Mar 2022 11:13:25 +0000
Subject: [New-bugs-announce] [issue47012] Speed up iteration of bytes and
 bytearray
Message-ID: <1647256405.01.0.318214910817.issue47012@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Benchmark and results are attached in the PR.

----------
messages: 415129
nosy: gvanrossum, kumaraditya303
priority: normal
pull_requests: 29965
severity: normal
status: open
title: Speed up iteration of bytes and bytearray
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 14 12:14:07 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Mar 2022 16:14:07 +0000
Subject: [New-bugs-announce] [issue47013] 3.10: test_bdb test_distutils fail
 on s390x Fedora Rawhide Clang Installed 3.10
Message-ID: <1647274447.55.0.120489432605.issue47013@roundup.psfhosted.org>


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

Since build 298, test_bdb test_distutils fail on s390x Fedora Rawhide Clang Installed 3.10:
https://buildbot.python.org/all/#/builders/694/builds/298

2 changes of build 298:

* bpo-46986: Upgrade bundled setuptools to 60.9.3 (GH-31820)(21 hours ago)
* [3.10] bpo-46985: Upgrade bundled pip to 22.0.4 (GH-31819) (GH-31849)(21 hours ago)

Logs:

0:02:03 load avg: 9.95 [213/427/1] test_distutils failed (uncaught exception) -- running: test_concurrent_futures (42.4 sec)
test test_distutils crashed -- Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/test/libregrtest/runtest.py", line 335, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/test/libregrtest/runtest.py", line 280, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/test/test_distutils.py", line 15, in <module>
    import distutils.tests
ModuleNotFoundError: No module named 'distutils.tests'

======================================================================
FAIL: test_skip (test.test_bdb.StateTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/test/test_bdb.py", line 730, in test_skip
    with TracerRun(self, skip=skip) as tracer:
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/test/test_bdb.py", line 448, in __exit__
    self.test_case.fail(err_msg)
  File "/home/dje/cpython-buildarea/3.10.edelsohn-fedora-rawhide-z.clang-installed/build/target/lib/python3.10/test/test_bdb.py", line 582, in fail
    raise self.failureException(msg) from None
AssertionError: Wrong event type at expect_set item 2, got 'call'
  Expected: ('line', 3, 'tfunc_import')
  Got:      ('call', 84, 'find_spec'),      ('quit',),

----------
components: Tests
messages: 415157
nosy: vstinner
priority: normal
severity: normal
status: open
title: 3.10: test_bdb test_distutils fail on s390x Fedora Rawhide Clang Installed 3.10
versions: Python 3.10

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

From report at bugs.python.org  Mon Mar 14 13:14:48 2022
From: report at bugs.python.org (Maximilian Hils)
Date: Mon, 14 Mar 2022 17:14:48 +0000
Subject: [New-bugs-announce] [issue47014] ProactorEventLoop ignores Ctrl+C
 after closing unrelated loop
Message-ID: <1647278088.02.0.528648197947.issue47014@roundup.psfhosted.org>


New submission from Maximilian Hils <python-bugs at maximilianhils.com>:

When a (second) ProactorEventLoop is garbage-collected, the current ProactorEventLoop starts to ignore Ctrl+C on Windows until it is woken up. The attached repro shows a minimal example. Uncommenting the `create_task` call or not using a second event loop fixes the behavior.

I couldn't find any shared/global objects in asyncio/windows_events.py, so I'm not sure what is causing this, or why the wakeup task helps.

FWIW, the second event loop in our code base originated from a stray `get_event_loop()` call, one more example that speaks in favor of `get_running_loop()`!

----------
components: asyncio
files: proactor-repro.py
messages: 415169
nosy: asvetlov, mhils, yselivanov
priority: normal
severity: normal
status: open
title: ProactorEventLoop ignores Ctrl+C after closing unrelated loop
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50675/proactor-repro.py

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

From report at bugs.python.org  Mon Mar 14 16:38:01 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Mon, 14 Mar 2022 20:38:01 +0000
Subject: [New-bugs-announce] [issue47015] Update tests from asyncore to
 asyncio
Message-ID: <1647290281.28.0.271890781969.issue47015@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

PEP 594 ? Removing dead batteries from the standard library [1] removes asyncore and asynchat in 3.12 with the following note:

> The asyncore module is also used in stdlib tests. The tests for ftplib, logging, smptd, smtplib, and ssl are partly based on asyncore. These tests must be updated to use asyncio or threading.

(Note: the tests for `os` module are not mentioned and smtpd will be removed in 3.12 along with its tests anyway)

I'm performing the update now to avoid keeping asynchat and asyncore as private subpackages of `test` package.

[1] https://peps.python.org/pep-0594/

----------
components: Tests
messages: 415185
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Update tests from asyncore to asyncio
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 14 17:21:37 2022
From: report at bugs.python.org (Illia Volochii)
Date: Mon, 14 Mar 2022 21:21:37 +0000
Subject: [New-bugs-announce] [issue47016] Create a test verifying bundled
 pip and setuptools wheels
Message-ID: <1647292897.69.0.328290401406.issue47016@roundup.psfhosted.org>


New submission from Illia Volochii <illia.volochii at gmail.com>:

Bundled pip and setuptools wheels have to be verified manually at the moment when they are upgraded.
We can automate this by comparing their checksums to ones provided by Warehouse?s JSON API (e.g., https://pypi.org/pypi/pip/json.)

Since such a check requires network activity and not to slow down tests, creating a GitHub Actions workflow that runs only when the files are changed is a good option.

I suggested this in https://github.com/python/cpython/pull/30178#issuecomment-998765841 originally.

----------
components: Library (Lib)
messages: 415193
nosy: illia-v
priority: normal
severity: normal
status: open
title: Create a test verifying bundled pip and setuptools wheels
type: enhancement
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/issue47016>
_______________________________________

From report at bugs.python.org  Mon Mar 14 18:25:32 2022
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Mar 2022 22:25:32 +0000
Subject: [New-bugs-announce] [issue47017] frozen modules are on by default
 in dev build
Message-ID: <1647296732.49.0.681504882715.issue47017@roundup.psfhosted.org>


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

At least on Windows and macOS, this repro shows that frozen modules are on in a dev build:

Mac:

~/cpython$ ./python.exe -c 'import os; print(os._exists.__code__)'
<code object _exists at 0x10dec7ee0, file "<frozen os>", line 41>

~/cpython$ ./python.exe -Xfrozen_modules=off -c 'import os; print(os._exists.__code__)'
<code object _exists at 0x10e851b50, file "/Users/guido/cpython/Lib/os.py", line 41>

On Windows, the same except use .\python.bat.

----------
messages: 415203
nosy: eric.snow, gvanrossum
priority: normal
severity: normal
status: open
title: frozen modules are on by default in dev build

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

From report at bugs.python.org  Mon Mar 14 18:41:25 2022
From: report at bugs.python.org (AverseMoon54797)
Date: Mon, 14 Mar 2022 22:41:25 +0000
Subject: [New-bugs-announce] [issue47018] ImportError: cannot import name
 '_simple_enum' from 'enum'
Message-ID: <1647297685.19.0.68502356884.issue47018@roundup.psfhosted.org>


New submission from AverseMoon54797 <trithomp32 at gmail.com>:

Why is this happening? Is there a fix for this I can't even fix the install because I get this error trying to reinstall cpython.

----------
messages: 415206
nosy: AverseMoon
priority: normal
severity: normal
status: open
title: ImportError: cannot import name '_simple_enum' from 'enum'

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

From report at bugs.python.org  Mon Mar 14 20:18:22 2022
From: report at bugs.python.org (hydroflask)
Date: Tue, 15 Mar 2022 00:18:22 +0000
Subject: [New-bugs-announce] [issue47019] Fatal Python Error in sqlite3
 Python 3.10
Message-ID: <1647303502.31.0.146964727203.issue47019@roundup.psfhosted.org>


New submission from hydroflask <hydroflask at yqxmail.com>:

_destructor in connection.c in Python 3.10+ now calls `PyGILState_Ensure()`, this is a problem because if the destructor is being called while the thread is being torn down it will cause an unbalanced/erroneous call to "PyEval_RestoreThread" in PyGILState_Ensure which will eventually trigger a Fatal Python Error. A perfect repro has been attached, should be run on Linux.

My recommended fix is to call sqlite3_close() within Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, and manually Py_DECREF all connection-related functions afterward.

----------
components: Extension Modules, Library (Lib)
files: sqlite3_fatal_python_error.py
messages: 415212
nosy: erlendaasland, hydroflask
priority: normal
severity: normal
status: open
title: Fatal Python Error in sqlite3 Python 3.10
type: crash
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50676/sqlite3_fatal_python_error.py

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

From report at bugs.python.org  Mon Mar 14 20:45:19 2022
From: report at bugs.python.org (Pablo Dumas)
Date: Tue, 15 Mar 2022 00:45:19 +0000
Subject: [New-bugs-announce] [issue47020] float('nan')==math.nan does NOT
 evaluate to True (as suggested by documentation).
Message-ID: <1647305119.03.0.119079591211.issue47020@roundup.psfhosted.org>


New submission from Pablo Dumas <pablodumas94 at gmail.com>:

float('nan')==math.nan  does NOT evaluate to True (as suggested by documentation).
    On the other hand, float('inf')==math.inf  DOES evaluate to True (as suggested by documentation).

Documentation we're referring to: https://docs.python.org/3.8/library/math.html

----------
assignee: docs at python
components: Documentation
messages: 415213
nosy: docs at python, w0rthle$$
priority: normal
severity: normal
status: open
title: float('nan')==math.nan  does NOT evaluate to True (as suggested by documentation).
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar 14 22:10:46 2022
From: report at bugs.python.org (Duck)
Date: Tue, 15 Mar 2022 02:10:46 +0000
Subject: [New-bugs-announce] [issue47021] Add separate match and case doc to
 pydoc
Message-ID: <1647310246.64.0.911179917615.issue47021@roundup.psfhosted.org>


New submission from Duck <duckboycool101 at gmail.com>:

Currently pydoc (and therefore things like the interactive help prompt) do not have documentation for the soft-keywords "match" and "case".

```
help> match
No Python documentation found for 'match'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.
```

I think that it would make sense for both of these prompts to give the docs for the match statement (https://docs.python.org/3/reference/compound_stmts.html#the-match-statement) similar to the other compound statements.

The "compound" doc already contains the match statement documentation, but is unnecessarily long at over 48000 characters, and is only accessed by the unhelpful named for this purpose "LOOPING" prompt. As soft keywords, they also might be best added in a separate section in "keywords" (and potentially with "_", although this already refers to "PRIVATENAMES" and is in "symbols").

A standalone match and case doc is not currently present in the Lib/pydoc_data/topics.py file automatically generated from documentation, and would need to be added in some way to do this.

----------
components: Library (Lib)
messages: 415217
nosy: duckboycool
priority: normal
severity: normal
status: open
title: Add separate match and case doc to pydoc
type: enhancement

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

From report at bugs.python.org  Tue Mar 15 03:27:58 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Tue, 15 Mar 2022 07:27:58 +0000
Subject: [New-bugs-announce] [issue47022] PEP 594: Document removal of
 asynchat, asyncore and smtpd
Message-ID: <1647329278.28.0.312815777301.issue47022@roundup.psfhosted.org>


New submission from Hugo van Kemenade <hugovk+python at gmail.com>:

PEP 594 ? Removing dead batteries from the standard library

As mentioned in the SC acceptance:

> One thing we?d like to see happen while implementing it: Document the status of the modules being deprecated and removed and backport those deprecation updates to older CPython branch documentation (at least back to 3.9). That gets the notices in front of more people who may use the docs for their specific Python version.

So let's update documentation and deprecation warnings to make clear in which release they're to be removed.

This first one is just for the three modules (asynchat, asyncore and smtpd) slated for removal soonest, in 3.12:

https://peps.python.org/pep-0594/#deprecated-modules

----------
components: Library (Lib)
messages: 415222
nosy: hugovk
priority: normal
severity: normal
status: open
title: PEP 594: Document removal of asynchat, asyncore and smtpd
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 15 04:17:57 2022
From: report at bugs.python.org (Siddhesh Sathe)
Date: Tue, 15 Mar 2022 08:17:57 +0000
Subject: [New-bugs-announce] [issue47023] re.sub shows key error on regex
 escape chars provided in repl param
Message-ID: <1647332277.42.0.883314287614.issue47023@roundup.psfhosted.org>


New submission from Siddhesh Sathe <siddheshsathe at rediffmail.com>:

Python 3.9.10 (main, Jan 15 2022, 18:56:52)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.sub(r"{\w}", "\s", "Hello! {user}")
Traceback (most recent call last):
  File "/usr/lib/python3.9/sre_parse.py", line 1039, in parse_template
    this = chr(ESCAPES[this][1])
KeyError: '\\s'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/re.py", line 210, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/usr/lib/python3.9/re.py", line 327, in _subx
    template = _compile_repl(template, pattern)
  File "/usr/lib/python3.9/re.py", line 318, in _compile_repl
    return sre_parse.parse_template(repl, pattern)
  File "/usr/lib/python3.9/sre_parse.py", line 1042, in parse_template
    raise s.error('bad escape %s' % this, len(this))
re.error: bad escape \s at position 0
>>>

----------
components: Regular Expressions
messages: 415225
nosy: ezio.melotti, mrabarnett, siddheshsathe
priority: normal
severity: normal
status: open
title: re.sub shows key error on regex escape chars provided in repl param
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar 15 04:28:31 2022
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Mar 2022 08:28:31 +0000
Subject: [New-bugs-announce] [issue47024] Update to OpenSSL 1.1.1n
Message-ID: <1647332911.51.0.546215674057.issue47024@roundup.psfhosted.org>


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

Update OpenSSL to 1.1.1n and test with OpenSSL 3.0.2. The update will become available later today and features a HIGH security bug, https://mta.openssl.org/pipermail/openssl-announce/2022-March/000216.html

$ sed -i 's/1.1.1m/1.1.1n/g' Tools/ssl/multissltests.py .azure-pipelines/pr.yml .azure-pipelines/ci.yml .github/workflows/build.yml PCbuild/python.props PCbuild/get_externals.bat Mac/BuildScript/build-installer.py
$ sed -i 's/3.0.1/3.0.2/g' Tools/ssl/multissltests.py .github/workflows/build.yml

----------
assignee: christian.heimes
components: Build, Windows, macOS
messages: 415226
nosy: christian.heimes, lukasz.langa, ned.deily, pablogsal, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Update to OpenSSL 1.1.1n
type: security
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Mar 15 06:32:43 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 15 Mar 2022 10:32:43 +0000
Subject: [New-bugs-announce] [issue47025] bytes do not work on sys.path
Message-ID: <1647340363.27.0.242980103727.issue47025@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

importing a module with bytes in `sys.path` fails with:

  File "<frozen importlib._bootstrap_external>", line 182, in _path_isabs
TypeError: startswith first arg must be bytes or a tuple of bytes, not str

(see reproducer in attached demo.py)

however `sys.path` is documented as supporting bytes "Only strings and bytes should be added to sys.path; all other data types are ignored during import." https://docs.python.org/3/library/sys.html?highlight=Only%20strings%20and%20bytes#sys.path

bytes are allowed in PathFinder._find_spec https://github.com/python/cpython/blob/2cf7f865f099db11cc6903b334d9c376610313e8/Lib/importlib/_bootstrap_external.py#L1460-L1462 but perhaps they should be ignored or explicitly fsdecoded ? 


see also:
https://bugs.python.org/issue32642
https://github.com/python/importlib_metadata/issues/372#issuecomment-1067799424

----------
files: demo.py
messages: 415233
nosy: graingert
priority: normal
severity: normal
status: open
title: bytes do not work on sys.path
Added file: https://bugs.python.org/file50678/demo.py

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

From report at bugs.python.org  Tue Mar 15 09:29:09 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 15 Mar 2022 13:29:09 +0000
Subject: [New-bugs-announce] [issue47026] BytesWarning in zipimport paths on
 sys.path
Message-ID: <1647350949.19.0.783799424166.issue47026@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

importing from a bytes zipimport path on sys.path results in a BytesWarning: Comparison between bytes and string

running the reproducer with `python -b` shows:
python -b zipfile_demo.py 
<frozen importlib._bootstrap_external>:1345: BytesWarning: Comparison between bytes and string

see also https://bugs.python.org/issue47025

----------
components: Library (Lib)
files: zipfile_demo.py
messages: 415245
nosy: graingert
priority: normal
severity: normal
status: open
title: BytesWarning in zipimport paths on sys.path
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50680/zipfile_demo.py

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

From report at bugs.python.org  Tue Mar 15 10:55:54 2022
From: report at bugs.python.org (Yann Droneaud)
Date: Tue, 15 Mar 2022 14:55:54 +0000
Subject: [New-bugs-announce] [issue47027] subprocess.run(),
 subprocess.Popen() should accept file descriptor as cwd parameter
Message-ID: <1647356154.7.0.125333178117.issue47027@roundup.psfhosted.org>


New submission from Yann Droneaud <ydroneaud at opteya.com>:

subprocess.run() and subprocess.Popen() accepts a cwd= parameter to change directory before running the subprocess.

Unfortunately it's not possible to use a file descriptor to run the subprocess in a directory already opened.

For example:

    import os
    import subprocess
    with os.open('/usr/bin', os.O_RDONLY) as f:
        subprocess.run(["ls", "-l"], cwd=f, check=True)

fails with

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.9/subprocess.py", line 505, in run
        with Popen(*popenargs, **kwargs) as process:
      File "/usr/lib/python3.9/subprocess.py", line 951, in __init__
        self._execute_child(args, executable, preexec_fn, close_fds,
      File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
        self.pid = _posixsubprocess.fork_exec(

Using a file descriptor instead of path is useful to address TOCTOU issues.

Maybe a mean to convert a file descriptor to a Path-like object would do the trick.

----------
components: Library (Lib)
messages: 415249
nosy: ydroneaud
priority: normal
severity: normal
status: open
title: subprocess.run(), subprocess.Popen() should accept file descriptor as cwd parameter
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Mar 15 11:38:25 2022
From: report at bugs.python.org (John K.)
Date: Tue, 15 Mar 2022 15:38:25 +0000
Subject: [New-bugs-announce] [issue47028] Incorrect behaviour when zipping a
 bunch of maps
Message-ID: <1647358705.36.0.73644114297.issue47028@roundup.psfhosted.org>


New submission from John K. <khoodolphin at gmail.com>:

map(f, itr) is supposed to be the lazy way to do [f(val) for val in itr]. However, when unpacking and zipping a list of maps, I get a different result from when evaluating eagerly. More precisely:

Python 3.10.2 | packaged by conda-forge | (main, Mar  8 2022, 15:53:57) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> maps = [map(lambda x: x**i, range(7)) for i in range(5)]
>>> for z in zip(*maps):
...     print(z)
...
(0, 0, 0, 0, 0)
(1, 1, 1, 1, 1)
(16, 16, 16, 16, 16)
(81, 81, 81, 81, 81)
(256, 256, 256, 256, 256)
(625, 625, 625, 625, 625)
(1296, 1296, 1296, 1296, 1296)
>>> lists = [[x**i for x in range(7)] for i in range(5)]
>>> for z in zip(*lists):
...     print(z)
...
(1, 0, 0, 0, 0)
(1, 1, 1, 1, 1)
(1, 2, 4, 8, 16)
(1, 3, 9, 27, 81)
(1, 4, 16, 64, 256)
(1, 5, 25, 125, 625)
(1, 6, 36, 216, 1296)

----------
components: Interpreter Core
messages: 415256
nosy: khoodolphin
priority: normal
severity: normal
status: open
title: Incorrect behaviour when zipping a bunch of maps
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar 15 14:28:33 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 15 Mar 2022 18:28:33 +0000
Subject: [New-bugs-announce] [issue47029] Fix a BrokenPipeError when a
 multiprocessing.Queue is garbage collected
Message-ID: <1647368913.23.0.350559928091.issue47029@roundup.psfhosted.org>


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

A `BrokenPipeError` exception is raised when the queue thread of a `multiprocessing.Queue` still sends enqueued items to the write end of the queue pipe *after* the read end of the queue pipe has been [automatically closed during its garbage collection](https://docs.python.org/3/library/socket.html#socket.socket.close) following the garbage collection of the queue (the write end of the queue pipe is not garbage collected because it is also referenced by the queue thread):

```
import multiprocessing

def main():
    q = multiprocessing.Queue()
    q.put(0)

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

----------
components: Library (Lib)
messages: 415272
nosy: maggyero
priority: normal
severity: normal
status: open
title: Fix a BrokenPipeError when a multiprocessing.Queue is garbage collected
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Mar 15 14:46:49 2022
From: report at bugs.python.org (Randolf Scholz)
Date: Tue, 15 Mar 2022 18:46:49 +0000
Subject: [New-bugs-announce] [issue47030] singledispatch does not work with
 positional arguments with default values.
Message-ID: <1647370009.1.0.761981911738.issue47030@roundup.psfhosted.org>


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

from functools import singledispatch
from typing import Optional

@singledispatch
def load(key: Optional[str] = None, /) -> None:
    raise NotImplementedError

@load.register
def _(key: None, /) -> None:
    print(f"loaded {key=}") 

@load.register
def _(key: str, /) -> None:
    print(f"loaded {key=}")
    
load()  # TypeError: load requires at least 1 positional argument

----------
messages: 415274
nosy: randolf.scholz
priority: normal
severity: normal
status: open
title: singledispatch does not work with positional arguments with default values.
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue Mar 15 18:47:25 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 15 Mar 2022 22:47:25 +0000
Subject: [New-bugs-announce] [issue47031] math.nan should note that NANs do
 not compare equal to anything
Message-ID: <1647384445.54.0.624569737197.issue47031@roundup.psfhosted.org>


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

The IEEE-754 requirement that NANs are never equal to anything, even to themselves, is a common stumbling block for those new to the consequences of IEEE-754. See for example #47020.

The documentation for math.nan would be a good place to add a note like

"Due to the requirements of the `IEEE-754 standard <https://en.wikipedia.org/wiki/IEEE_754>`_, math.nan and float('nan') are never equal to any other value, including themselves. Use math.isnan to test for NANs."

https://docs.python.org/3.8/library/math.html#math.nan

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 415302
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: math.nan should note that NANs do not compare equal to anything
type: enhancement
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/issue47031>
_______________________________________

From report at bugs.python.org  Tue Mar 15 20:20:54 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 16 Mar 2022 00:20:54 +0000
Subject: [New-bugs-announce] [issue47032] CI does not detect launcher
 installer build failure
Message-ID: <1647390054.87.0.900076587852.issue47032@roundup.psfhosted.org>


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

When changes are made under the Tools/msi directory, extra tests are run in GitHub Actions to build the installer.

Apparently, these tests do not fail when the launcher installer fails to build. They need to.

----------
assignee: steve.dower
messages: 415308
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: CI does not detect launcher installer build failure
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Mar 15 21:19:48 2022
From: report at bugs.python.org (Ghyslain Leclerc)
Date: Wed, 16 Mar 2022 01:19:48 +0000
Subject: [New-bugs-announce] [issue47033] Build failure on macOS Big Sur
Message-ID: <1647393588.68.0.457618836458.issue47033@roundup.psfhosted.org>


New submission from Ghyslain Leclerc <ghleclerc at gmail.com>:

I have tried to compile python on macOS and I have failed.

I have cloned the cpython repository, then used ./configure and make.  There are build errors on my system.  They seem related to https://bugs.python.org/issue42692.

I have tried the __has_builtin(__builtin_available) code in a single main.c file and it compiles and has the appropriate behavior.  I have then tried to add #warnings in the file posixmodule.c.  It seems that when compiling this file, the preprocessor define does not work.

I run macOS version 11.6.4 (20G417).  I have Xcode Version 13.0 (13A233).  The compiler version is:
  Apple clang version 13.0.0 (clang-1300.0.29.3)
  Target: x86_64-apple-darwin20.6.0

Thank you.

----------
components: macOS
messages: 415312
nosy: Ghyslain Leclerc, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Build failure on macOS Big Sur
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Wed Mar 16 10:24:35 2022
From: report at bugs.python.org (jeffersonqin)
Date: Wed, 16 Mar 2022 14:24:35 +0000
Subject: [New-bugs-announce] [issue47034] pickle not working correctly when
 custom field is directly initialized by constructors
Message-ID: <1647440675.94.0.131191569547.issue47034@roundup.psfhosted.org>


New submission from jeffersonqin <1247006353 at qq.com>:

For the following code piece:

```
import pickle

class Child:
	def __init__(self, field):
		self.field = field

class Parent:
	child = Child(0.5)

if __name__ == '__main__':
	i = input()
	if i == 'd':
		parent = Parent()
		parent.child.field = 0.6
		pickle.dump(parent, open('test.pkl', 'wb+'))
	else:
		parent = pickle.load(open('test.pkl', 'rb'))
		print(parent.child.field)
```

After dumping, when we load the file throught `pickles.load`, `parent.child.field` is 0.5, and is not 0.6, which we intend it to be.

However, after removing the line `child = Child(0.5)` and moving it to `__init__(self)` of `Parent`, everything works fine.

I'm not sure whether this is indeed an issue. If not, sorry for take your time.

----------
components: Library (Lib)
files: test.py
messages: 415341
nosy: jeffersonqin
priority: normal
severity: normal
status: open
title: pickle not working correctly when custom field is directly initialized by constructors
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50682/test.py

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

From report at bugs.python.org  Wed Mar 16 10:25:28 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Mar 2022 14:25:28 +0000
Subject: [New-bugs-announce] [issue47035] Rewrite asyncio queue tests with
 IsolatedAsyncioTestCase
Message-ID: <1647440728.46.0.0769834491684.issue47035@roundup.psfhosted.org>


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

It can help with future maintenance a lot.  Current tests are cumbersome.

----------
components: asyncio
messages: 415342
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Rewrite asyncio queue tests with IsolatedAsyncioTestCase
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Mar 16 13:16:49 2022
From: report at bugs.python.org (munky)
Date: Wed, 16 Mar 2022 17:16:49 +0000
Subject: [New-bugs-announce] [issue47036] Nested list in Dict,
 multiprocessing manager
Message-ID: <1647451009.46.0.388425415857.issue47036@roundup.psfhosted.org>


New submission from munky <munky99999 at gmail.com>:

Sorry for this post but I found an unusual behaviour.

from multiprocessing import Manager
manager = Manager()

managerdict = manager.dict()

managerdict["first"]= {"stat" : [0,1]}

managerdict["first"]["stat"][0] += 1
managerdict["first"]["stat"][1] += 1

print(managerdict)

anotherdict = {}
anotherdict['foo'] = {"stat" : [0, 1]}
anotherdict['foo']["stat"][0] += 1
anotherdict['foo']["stat"][1] += 1

print(anotherdict)

Which outputs:

{'first': {'stat': [0, 1]}}
{'foo': {'stat': [1, 2]}}

What am I doing wrong?

Thanks!

----------
components: Library (Lib)
messages: 415353
nosy: munky99999
priority: normal
severity: normal
status: open
title: Nested list in Dict, multiprocessing manager
type: behavior

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

From report at bugs.python.org  Wed Mar 16 14:30:03 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Mar 2022 18:30:03 +0000
Subject: [New-bugs-announce] [issue47037] Build problems on Windows
Message-ID: <1647455403.28.0.516957856389.issue47037@roundup.psfhosted.org>


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

3.11 apparently builds without error, and 'python' and 'python -m idlelib' appears to start normally, but there is a new problem.
  python -m test
raises OS box with 'Debug Assertion Failed!', program python_d.exe,
File minkernal\crts\ucrt\src\time\wcsftime.exe
Line 1184, expression false.
Dismiss box and a few tests run until box repeats and Command Prompt eventually locks.
...test test_idle finished OK once after dismissing box.  On retry, test ran OK but CP locked instead of showing new prompt.

3.10 and 3.9 (but not 3.11): compiling show a newish warning.
  pythonw.vcxproj -> f:\dev\310\PCbuild\amd64\pythonw_d.exe
  pythonw.vcxproj -> f:\dev\310\PCbuild\amd64\pythonw_d.pdb (Full PDB)
f:\dev\310\PCbuild\pythoncore.vcxproj(554,5): warning : A copy of vcruntime140.dll is also required

Does not 3.11 also require this? (wherever it is supposed to be?).  Aside from the warning, 3.10 appear to be working normally.  There is no error box when starting tests and 50 have run so far without a box.

----------
components: Build, Windows
messages: 415355
nosy: lukasz.langa, pablogsal, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Build problems on Windows
type: compile error
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Mar 16 15:22:03 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Mar 2022 19:22:03 +0000
Subject: [New-bugs-announce] [issue47038] Rewrite asyncio.wait_for test to
 use IsolatedAsyncioTestCase
Message-ID: <1647458523.65.0.149238052361.issue47038@roundup.psfhosted.org>


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

It simplifies future maintenance.

----------
components: Tests, asyncio
messages: 415359
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Rewrite asyncio.wait_for test to use IsolatedAsyncioTestCase
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Mar 16 19:53:06 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Mar 2022 23:53:06 +0000
Subject: [New-bugs-announce] [issue47039] Normalize asyncio future and task
 repr()
Message-ID: <1647474786.61.0.902124780631.issue47039@roundup.psfhosted.org>


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

Return `...` in the case of recursive representation.

Now the only result is replaced with `...`, all other future properties are still printed.  
It doesn't follow `repr()` for other stdlib objects.

----------
components: asyncio
messages: 415375
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Normalize asyncio future and task repr()
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 17 01:35:08 2022
From: report at bugs.python.org (Ma Lin)
Date: Thu, 17 Mar 2022 05:35:08 +0000
Subject: [New-bugs-announce] [issue47040] Remove an invalid versionchanged
 in doc
Message-ID: <1647495308.71.0.557199294207.issue47040@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

Since CPython 3.0.0, the checksums are always truncated to `unsigned int`:
https://github.com/python/cpython/blob/v3.0/Modules/zlibmodule.c#L930
https://github.com/python/cpython/blob/v3.0/Modules/zlibmodule.c#L950

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 415386
nosy: docs at python, gregory.p.smith, malin
priority: normal
severity: normal
status: open
title: Remove an invalid versionchanged in doc
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Mar 17 01:39:59 2022
From: report at bugs.python.org (yonghao hu)
Date: Thu, 17 Mar 2022 05:39:59 +0000
Subject: [New-bugs-announce] [issue47041] requests module parse url failed
Message-ID: <1647495599.59.0.763514720796.issue47041@roundup.psfhosted.org>


New submission from yonghao hu <cc97654321 at 163.com>:

Run the following code or report an error, and the URL is a normal URL?
'''
python3 -c "import requests;requests.get('http://183.246.199.100:8321')"
'''
Error code?
'''
requests.exceptions.InvalidURL: Failed to parse: http://183.246.199.100:8321:8321/SSO/EnrollList
'''

----------
components: Parser
messages: 415387
nosy: cc97654321, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: requests module parse url failed
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar 17 06:57:10 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Mar 2022 10:57:10 +0000
Subject: [New-bugs-announce] [issue47042] Fix test_html_doc in test_pydoc
Message-ID: <1647514630.11.0.12702662455.issue47042@roundup.psfhosted.org>


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

Due to missed splitlines() in test_pydoc the HTML output was not tested correctly. Instead of testing that the actual output contains every *line* from the expected output it tested that the actual output contains every *character* from the expected output. The test would pass with any actual output which contains all Latin letters and some punctuation.

The following PR fixes this bug and makes the test even more strict. Now it tests that the actual output contains the same lines as the expected output, in the same order, ignoring indentation and empty lines.

----------
components: Tests
messages: 415396
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix test_html_doc in test_pydoc
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Mar 17 09:49:54 2022
From: report at bugs.python.org (rive_n)
Date: Thu, 17 Mar 2022 13:49:54 +0000
Subject: [New-bugs-announce] [issue47043] Argparse can't parse subparsers
 with parse_known_args
Message-ID: <1647524994.61.0.940749160258.issue47043@roundup.psfhosted.org>


New submission from rive_n <rivenfornotifications at gmail.com>:

Let's say we have default parser configuration:
https://docs.python.org/3/library/argparse.html#other-utilities

Like this one:

```python3
import argparse

parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--foo', action='store_true', help='foo help')
subparsers = parser.add_subparsers(help='sub-command help')

# create the parser for the "a" command
parser_a = subparsers.add_parser('a', help='a help')
parser_a.add_argument('-a', help='bar help')

# create the parser for the "b" command
parser_b = subparsers.add_parser('b', help='b help')
parser_b.add_argument('-b', help='baz help')

```

So i want to parse all subparsers arguments. For this purpose i could use `parse_known_args` method. 

But for some reason there is no way to get all of current args specified via command prompt or via list:
`print(parser.parse_known_args(['a', '-a', '12', 'b', '-b', '32']))` - will not print 'a' and 'b' data. It will only contain first valid argument; 

This is pretty strange behavior. Why i can't just get all of actions (subparsers) ?

----------
components: Parser
messages: 415412
nosy: lys.nikolaou, pablogsal, rive-n
priority: normal
severity: normal
status: open
title: Argparse can't parse subparsers with parse_known_args
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar 17 12:08:00 2022
From: report at bugs.python.org (Laurent Delphin)
Date: Thu, 17 Mar 2022 16:08:00 +0000
Subject: [New-bugs-announce] [issue47044] Python 2.7.18 + tck/tk 8.6.1 + Osx
 Lion : tkinter built failes
Message-ID: <1647533280.64.0.67321104584.issue47044@roundup.psfhosted.org>


New submission from Laurent Delphin <laurentang001 at gmail.com>:

Hello Python developers :

The module tkinter failed to be built for Python 2.7.18, although for Python 3,it works with the following test : python -m tkinter. It doesn't with Python2. 
Configuration :
Mac osx Lion 10.7.5.
Python2 : 2.7.18
Compiler : clang (Xcode).
Tcl/Tk : 8.6.12.
If I succeed, log files will be enclosed hereby.
Thank you.

----------
messages: 415421
nosy: laurentang001
priority: normal
severity: normal
status: open
title: Python 2.7.18 + tck/tk 8.6.1 + Osx Lion : tkinter built failes
type: compile error

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

From report at bugs.python.org  Thu Mar 17 12:23:10 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 17 Mar 2022 16:23:10 +0000
Subject: [New-bugs-announce] [issue47045] Remove the RESUME instruction
Message-ID: <1647534190.7.0.0573728232462.issue47045@roundup.psfhosted.org>


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

The RESUME instruction was added to make resumption points explicit in the bytecode. This makes it easier to implement tracing, quickening, and interrupt checks as there is an explicit place to perform these checks.

Unfortunately, it also has considerable overhead. So we should remove it.
To do that, we need to:
1. Remove f_state from the InterpreterFrame so we don't need to update it.
2 .Quicken automatically in the adaptive instructions.
3. Check the evalbreaker when resuming a frame in the interpreter.
4. Add some metadata to the code object, so that we know when to fire "call" events when tracing.

----------
assignee: Mark.Shannon
messages: 415424
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Remove the RESUME instruction
type: performance

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

From report at bugs.python.org  Thu Mar 17 12:40:39 2022
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 17 Mar 2022 16:40:39 +0000
Subject: [New-bugs-announce] [issue47046] Add `f_state` attribute to
 FrameObjects.
Message-ID: <1647535239.19.0.523349265892.issue47046@roundup.psfhosted.org>


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

When tracing, the event supplied is insufficient to determine what is actually happening.

E.g. A "call" event could be a call to a function or resuming a generator or coroutine.

Adding a state field to the FrameObject would allow these cases to be disambiguated without having to make dubious deductions from `f_lasti` or other frame attributes.

The proposed states would be:

FRAME_CREATED    # Frame created, but not executed at all
FRAME_SUSPENDED  # Frame suspended after yield or yield from
FRAME_EXECUTING  # Frame is executed normally
FRAME_COMPLETED  # Frame has completed 
FRAME_CLEARED    # Frame has been cleared


Ned, any other states that you might need to know about?

----------
messages: 415427
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Add `f_state` attribute to FrameObjects.

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

From report at bugs.python.org  Thu Mar 17 12:48:39 2022
From: report at bugs.python.org (Mikael Koli)
Date: Thu, 17 Mar 2022 16:48:39 +0000
Subject: [New-bugs-announce] [issue47047] smtplib: allow custom policy or
 use msg.policy in send_message
Message-ID: <1647535719.92.0.354581918183.issue47047@roundup.psfhosted.org>


New submission from Mikael Koli <koli.mikael at gmail.com>:

The method smtplib.SMTP.send_message does not use the message's Policy if all of the from_addrs or to_addrs are not international. See: https://github.com/python/cpython/blob/v3.10.3/Lib/smtplib.py#L983 (unchanged in current main). The email.generator.BytesGenerator does not capture the email's policy as it was not passed to its init.

This has at least one notable setback: you cannot set the mangle_from to False meaning that the method will always turn "From ..." to ">From ..." in the plain text part (though often that is desirable). This is especially confusing as email library has the mangle_from as False by default for EmailMessages but smtplib.SMTP's send_message does not respect this by default.

The smtplib.SMTP.send_message has a mention about this in the docstring thus not entirely sure if intentional:

    ... Otherwise the generator is called without modifying the
        policy.


If we changed this line: https://github.com/python/cpython/blob/v3.10.3/Lib/smtplib.py#L983

from this:
    g = email.generator.BytesGenerator(bytesmsg)

to this:
    g = email.generator.BytesGenerator(bytesmsg, policy=msg.policy.clone()

smptlib's tests are passed but I suspect it's not that simple. The docstring mention indicates this is at some level intentional and I think the mangle_from needs to remain True as otherwise, it may cause security problems in existing code. Another option perhaps could be that the policy could be passed with the send_message and that is used if not None or we could have argument "msg_policy=False" that if True, the message's policy is used.

One could also think that this could be overcome by subclassing the SMTP. However, the logic is such deep in that it is not convenient.

So in short, the options I thought of:
- Have an argument "policy" in send_message to force usage of your own policy (safe option)
- Have an argument "msg_policy" (name debatable) in send_message and if True, the message's policy is always used (safe option)
- Use the message's policy always (unsafe, possibly breaking and causing security issues in existing code)

----------
components: Library (Lib), email
messages: 415428
nosy: Miksus, barry, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib: allow custom policy or use msg.policy in send_message
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/issue47047>
_______________________________________

From report at bugs.python.org  Thu Mar 17 13:00:07 2022
From: report at bugs.python.org (Laurent Delphin)
Date: Thu, 17 Mar 2022 17:00:07 +0000
Subject: [New-bugs-announce] [issue47048] Python 3.10.3 + Osx Lion : fatal
 error (make) signalmodule or more
Message-ID: <1647536407.51.0.0999811283469.issue47048@roundup.psfhosted.org>


New submission from Laurent Delphin <laurentang001 at gmail.com>:

Hello developers :

Hereafter somme comments about a fatal error when Running make. Enclosed log (txt) files if I succeed in uploading them. 
Python3 : 3.10.3.
Osx : Lion 10.7.5. 
Compiler family : clang (Xcode). 

Message :
return PyErr_SetFromErrno(PyExec_OSError) ;
fatal error : error in backend etc.

Kind regards,

----------
messages: 415429
nosy: laurentang001
priority: normal
severity: normal
status: open
title: Python 3.10.3 + Osx Lion : fatal error (make) signalmodule or more
type: compile error

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

From report at bugs.python.org  Thu Mar 17 14:50:19 2022
From: report at bugs.python.org (Zoltan Vajda)
Date: Thu, 17 Mar 2022 18:50:19 +0000
Subject: [New-bugs-announce] [issue47049] Incorrect shutil.copytree()
 behaviour with symlinks
Message-ID: <1647543019.32.0.96447570107.issue47049@roundup.psfhosted.org>


New submission from Zoltan Vajda <vzvzvz2 at gmail.com>:

shutil.copytree incorrectly does not copy symlink contents if called
with symlink=False and ignore_dangling_symlinks=True.

The wrong behaviour can be reproduced like this:

$ tree
.
??? a
    ??? a.txt
    ??? b
        ??? a.txt -> ../a.txt

$ python3 -c "import shutil;shutil.copytree('a/b', 'c', symlinks=False, ignore_dangling_symlinks=True)"

As a result directoy c will be created but it will remain empty.
Expected result is a file c/a.txt with the contents of a/b/a.txt.

----------
components: Library (Lib)
messages: 415437
nosy: vajdaz
priority: normal
severity: normal
status: open
title: Incorrect shutil.copytree() behaviour with symlinks
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 17 14:51:45 2022
From: report at bugs.python.org (Alex Waygood)
Date: Thu, 17 Mar 2022 18:51:45 +0000
Subject: [New-bugs-announce] [issue47050] Cannot install Python 3.10.3 on
 Windows
Message-ID: <1647543105.33.0.65197408482.issue47050@roundup.psfhosted.org>


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

I have tried several times now to upgrade to Python 3.10.3 using the 64-bit installer for Windows at https://www.python.org/downloads/release/python-3103/. Each time, I encounter an error message stating that "The feature you are trying to use is on a network resource that is unavailable". Further error messages include statements that "The older version of Python 3.10.3 Test Suite (64-bit) cannot be removed", and finally, "0x80070643 - Fatal error during installation".

Screenshots of the full error messages are attached.

Hardware details:
- Microsoft Windows 10 Home, Version 10.0.19043 Build 19043
- A x64-based PC
- An HP Pavilion Notebook laptop
- Processor AMD A8-7410 APU

Does anybody have any idea what might be going wrong?

I initially tried installing Python 3.10.3 with 3.10.2 still installed, but have now uninstalled Python 3.10.2 from my machine. It has made no difference.

----------
components: Windows
files: error_messages-compressed.pdf
messages: 415438
nosy: AlexWaygood, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot install Python 3.10.3 on Windows
versions: Python 3.10
Added file: https://bugs.python.org/file50686/error_messages-compressed.pdf

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

From report at bugs.python.org  Thu Mar 17 16:39:27 2022
From: report at bugs.python.org (Donald O'Donnell)
Date: Thu, 17 Mar 2022 20:39:27 +0000
Subject: [New-bugs-announce] [issue47051] Windows v3.10.3 .chm file (in
 python310\doc) page headings are messed up and spread out over several
 lines. Also the font has changed from the former san serif font to a
 smaller and harder to read serif font.
Message-ID: <1647549567.72.0.246808188141.issue47051@roundup.psfhosted.org>


Change by Donald O'Donnell <DonnieODonnell at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: DonnieODonnell, docs at python
priority: normal
severity: normal
status: open
title: Windows v3.10.3 .chm file (in python310\doc) page headings are messed up and spread out over several lines. Also the font has changed from the former san serif font to a smaller and harder to read serif font.
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar 17 17:03:45 2022
From: report at bugs.python.org (arne123)
Date: Thu, 17 Mar 2022 21:03:45 +0000
Subject: [New-bugs-announce] [issue47052] allow string as sep in
 _Py_strhex_impl ( bytearray.hex() )
Message-ID: <1647551025.23.0.82482579805.issue47052@roundup.psfhosted.org>


New submission from arne123 <arne at pagelnet.de>:

I use Python to support some C development.
Often I need to convert bytearrays to C like convention:
0x12, 0x34

It would be very convenient for this use case if the separator could be a string (like ", 0x") instead of just a single character.

----------
components: IO
messages: 415447
nosy: arne123
priority: normal
severity: normal
status: open
title: allow string as sep in _Py_strhex_impl ( bytearray.hex() )
type: enhancement

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

From report at bugs.python.org  Thu Mar 17 18:44:38 2022
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 17 Mar 2022 22:44:38 +0000
Subject: [New-bugs-announce] [issue47053] Reduce de-optimization in
 BINARY_OP_INPLACE_ADD_UNICODE
Message-ID: <1647557078.86.0.480735606049.issue47053@roundup.psfhosted.org>


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

There was a discussion here: https://github.com/faster-cpython/ideas/discussions/269

Checking for whether the assignment target is the left-hand side, rather than just checking for the right refcount, is more stable and reduces the number of deoptimizations, and even increases performance on some benchmarks.

Note that `PyUnicode_Append` is already a somewhat expensive function that already checks for the right reference counts, so it's fine to let as much code as possible get there, even if it will take the slow path -- we mostly just want to reduce allocations and avoid the quadratic string concatenation otherwise.

----------
components: Interpreter Core
messages: 415455
nosy: Dennis Sweeney, brandtbucher
priority: normal
severity: normal
status: open
title: Reduce de-optimization in BINARY_OP_INPLACE_ADD_UNICODE
type: security
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 17 21:17:42 2022
From: report at bugs.python.org (Bluenix)
Date: Fri, 18 Mar 2022 01:17:42 +0000
Subject: [New-bugs-announce] [issue47054] "SyntaxError: non-default argument
 follows default argument" should be "parameter"
Message-ID: <1647566262.9.0.238891960992.issue47054@roundup.psfhosted.org>


New submission from Bluenix <bluenixdev at gmail.com>:

Running the code below will produce a SyntaxError with the message: "non-default argument follows default argument".

    def test(a=None, b):
        return b if a is None else a

The issue is that `a` and `b` aren't *arguments*, rather, they are *parameters*. The error message should be changed to: "non-default parameter follows default parameter".

This change appears simple enough and although it is not something I've found to be troublesome, it will help users to use correct keywords (arguments vs. parameters) when searching on the internet.

----------
components: Interpreter Core
messages: 415463
nosy: Bluenix2
priority: normal
severity: normal
status: open
title: "SyntaxError: non-default argument follows default argument" should be "parameter"
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar 17 22:52:35 2022
From: report at bugs.python.org (mobiusklein)
Date: Fri, 18 Mar 2022 02:52:35 +0000
Subject: [New-bugs-announce] [issue47055] `issubclass` on two different
 subclasses of abstract base class like `os.PathLike` returns unexpected
 value on early versions of Py3.7 and Py3.8
Message-ID: <1647571955.22.0.67382471148.issue47055@roundup.psfhosted.org>


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

The following code looks correct:

```python
import os

class A(os.PathLike):
    pass

class B(os.PathLike):
    pass

assert issubclass(A, os.PathLike) # direct inheritance relationship
assert issubclass(B, os.PathLike) # direct inheritance relationship
assert not issubclass(A, B) # A is not derived from B or vice-versa
```

On Python 3.7.0-3.7.6 and 3.8.0-3.8.1 the third assertion fails. The expected behavior was restored in 3.7.7 and 3.8.2. This seems to be around when the internals of `abc` were translated to C.

Given that the behavior was fixed, but a bug fix matching this behavior wasn't listed in the changelog, the only resolution is to document that this behavior may be extant in older but still supported minor versions of Python. Where should that text be placed?

----------
components: Library (Lib)
messages: 415467
nosy: mobiusklein
priority: normal
severity: normal
status: open
title: `issubclass` on two different subclasses of abstract base class like `os.PathLike` returns unexpected value on early versions of Py3.7 and Py3.8
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar 18 05:27:33 2022
From: report at bugs.python.org (Shin-Myoung-Serp)
Date: Fri, 18 Mar 2022 09:27:33 +0000
Subject: [New-bugs-announce] [issue47056] turtle.write() causes flickering
 when the tracer is turned off.
Message-ID: <1647595653.53.0.61025954383.issue47056@roundup.psfhosted.org>


New submission from Shin-Myoung-Serp <relent95 at naver.com>:

When implementing an animation with turtle, usually the tracer is turned off via turtle.tracer(0, 0) and turtle.update() is called manually.

When the tracer is off, most of drawing functions skips update() calls on the underlying Canvas. But turtle.write() does not do that.
(See the implementation of TurtleScreenBase._write().)

This causes flickering, as can be seen when you run the attached script. (Press space key to hide/show texts.)

----------
components: Library (Lib)
files: test_anim_write.py
messages: 415475
nosy: relent95
priority: normal
severity: normal
status: open
title: turtle.write() causes flickering when the tracer is turned off.
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50690/test_anim_write.py

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

From report at bugs.python.org  Fri Mar 18 08:21:57 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Mar 2022 12:21:57 +0000
Subject: [New-bugs-announce] [issue47057] Use FASTCALL convention for
 FutureIter.throw()
Message-ID: <1647606117.3.0.361797260817.issue47057@roundup.psfhosted.org>


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

All other asyncio functions are converted to fast calls already.

----------
components: asyncio
messages: 415489
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Use FASTCALL convention for FutureIter.throw()
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 18 09:20:22 2022
From: report at bugs.python.org (Jakub Kulik)
Date: Fri, 18 Mar 2022 13:20:22 +0000
Subject: [New-bugs-announce] [issue47058] Skip tests failing on Solaris
 worker
Message-ID: <1647609622.01.0.142147822424.issue47058@roundup.psfhosted.org>


New submission from Jakub Kulik <jakub.kulik at oracle.com>:

There are several tests failing on the recently added Solaris buildbot worker. This Issue aims to fix/skip the to make Solaris green on buildbot.

################
## test_posix ##
################

Issues with the `os.sched_get_priority_min`; fix offered here: https://bugs.python.org/issue41839

#################
## test_shutil ##
#################

Issues with `sendfile` being disabled on Solaris (and test suite not being able to handle that); fix offered here: https://bugs.python.org/issue41843

#################
## test_locale ##
#################

Strxfrm does not work in the current implementation due to the difference in Solaris locale encoding (most of which was solved with https://bugs.python.org/issue43667).

Internally we have fixed this issue with:
https://github.com/oracle/solaris-userland/blob/master/components/python/python39/patches/24-strxfrm-fix.patch

But this idea was previously rejected in https://bugs.python.org/issue16258

Because of that, those tests are skipped on Solaris in the attached PR.

#############
## test_re ##
#############

On SPARC there are some weird matches in some regexes:
Traceback (most recent call last):
  File ".../build/Lib/test/test_re.py", line 1907, in test_locale_caching
    self.check_en_US_utf8()
  File ".../build/Lib/test/test_re.py", line 1924, in check_en_US_utf8
    self.assertIsNone(re.match(b'\xc5', b'\xe5', re.L|re.I))
AssertionError: <re.Match object; span=(0, 1), match=b'\xe5'> is not None

I have no idea why this is happening. I presume it is locale related, but I didn't find anything problematic yet.

The simplest way to reproduce this is (meaning that this probably isn't caching related):
```
import locale
import re

locale.setlocale(locale.LC_CTYPE, 'en_US.utf8')
print(re.match(b'\xc5', b'\xe5', re.L|re.I))
```

This returns:
<re.Match object; span=(0, 1), match=b'\xe5'> on Solaris and None on Linux.

I am happy to investigate it further; any pointers as for where to look would be appreciated as I am stuck a little bit.

#################
## test_socket ##
#################

There are two issues here. The first one is similar to what BSD, Darwin and AIX experience with testFDPass tests:
https://bugs.python.org/issue22397
https://bugs.python.org/issue12958
These tests are skipped on Solaris in the attached PR.

The other one is an incorrect assumption about CMSG_SPACE on SPARC Solaris; it grows slightly sooner when increasing length compared to other platforms I tested.

with toobig == 2147483632
length     socket.CMSG_SPACE output
2147483619 2147483632
2147483620 2147483632
2147483621 2147483640
2147483622 2147483640
2147483623 2147483640
2147483624 2147483640
2147483625 2147483640
2147483626 2147483640
2147483627 2147483640
2147483628 2147483640
2147483629  <- OverflowError

======================================================================
ERROR: testCMSG_SPACE (test.test_socket.CmsgMacroTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builds/jkulik/testing/components/python/python39/Python-3.9.9/Lib/test/test_socket.py", line 3360, in testCMSG_SPACE
    ret = socket.CMSG_SPACE(n)
OverflowError: CMSG_SPACE() argument out of range

(on other platforms, increases generally happen with lengths divisible by 8, meaning that it gets all the way to 2147483631).

I am unsure how to fix this (currently, PR includes change we use internally but is likely not acceptable) as I don't know how to correctly guess the largest CMSG_SPACE on all platforms. Is it even necessary though (it can test OverflowError on other values than just the first failing one and can end slightly sooner)?

###############
## test_time ##
###############

This was recently fixed with: https://bugs.python.org/issue46099

----------
components: Tests
messages: 415493
nosy: kulikjak
priority: normal
severity: normal
status: open
title: Skip tests failing on Solaris worker
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Mar 18 14:00:50 2022
From: report at bugs.python.org (Arie Bovenberg)
Date: Fri, 18 Mar 2022 18:00:50 +0000
Subject: [New-bugs-announce] [issue47059] Mechanism to enable __weakref__
 slot on dataclass(slots=True)
Message-ID: <1647626450.19.0.913464434191.issue47059@roundup.psfhosted.org>


New submission from Arie Bovenberg <a.c.bovenberg at gmail.com>:

As discussed in bpo-46382, dataclasses may want to support the __weakref__ slot.

Currently, automatically slotted dataclasses are not given a __weakref__ slot. This makes auto-slotted dataclasses incompatible with weakref.

The attrs library has chosen for the following approeach:
- when slots are generated, a __weakref__ slot is added by default
- this may be optionally disabled with the weakref_slot=False flag

See this discussion on why that approach was taken: https://github.com/python-attrs/attrs/pull/420

The question for dataclass is: do we want to follow suit? Or perhaps make __weakref__ slot opt-in instead of opt-out?

----------
components: Library (Lib)
messages: 415515
nosy: ariebovenberg, eric.smith
priority: normal
severity: normal
status: open
title: Mechanism to enable __weakref__ slot on dataclass(slots=True)
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 18 14:11:51 2022
From: report at bugs.python.org (David Robertson)
Date: Fri, 18 Mar 2022 18:11:51 +0000
Subject: [New-bugs-announce] [issue47060] importlib.metadata.version can
 return None
Message-ID: <1647627111.5.0.916218060724.issue47060@roundup.psfhosted.org>


New submission from David Robertson <david.m.robertson1 at gmail.com>:

Originally written up at the typeshed repo: https://github.com/python/typeshed/issues/7513. The conclusion was that this is a bug in the implementation rather than an incorrect annotation.

To my surprise, I discovered in https://github.com/matrix-org/synapse/issues/12223 that it is possible for `importlib.metadata.version(...)` to return `None`. To reproduce this:

1. Create a new virtual environment. I'm using CPython 3.10.2 as my interpreter.
2. Within the venv, `pip install bottle`. (Any package will do; I choose `bottle` because it's small and doesn't have any dependencies).
3. Check importlib reports the `version` of `bottle`:
   ```python
   >>> import importlib.metadata as m
   >>> m.version('bottle')
   '0.12.19'
   ```
4. Here's the dirty bit: remove the metadata files for that package but keep the metadata directory.
   - Use `pip show bottle` to find the `site-packages` location
   - From there, remove all files in the `bottle-VERSION-.dist-info` directory: `rm /path/to/site-packages/bottle-VERSION.dist-info/*'.
5. The `version` of `bottle` is now judged to be `None`:
   ```python
   >>> import importlib.metadata as m
   >>> m.version("bottle") is None
   True
   ```
   `pip show bottle` now determines that `bottle` isn't installed:
   ```shell
   $ pip show bottle
   WARNING: Package(s) not found: bottle
   ```

As well as importlib.metadata.version, importlib.metadata.Distribution.version and importlib.metadata.Distribution.name return None in this situation.

I couldn't see any suggestion in the stdlib docs (https://docs.python.org/3.10/library/importlib.metadata.html#distribution-versions) that this was possible. (Aside: it'd be great if the docs mention that PackageNotFoundError is raised if a package is not installed.)

No-one in their right mind should do step 4 willingly, but I have seen it happen in the wild (https://github.com/matrix-org/synapse/issues/12223). We suspected a botched backup or similar was to blame.

I'm not familiar with all the machinery of Python package management, but I think I'd expect there to be a PackageNotFoundError raised in this situation? (I can imagine a package that doesn't declare its version, where `version()` returning `None` might make sense; but that feels odd.) Is the behaviour as intended?

It looks like this might be related to https://github.com/python/importlib_metadata/issues/371?

----------
components: Library (Lib)
messages: 415516
nosy: David Robertson
priority: normal
severity: normal
status: open
title: importlib.metadata.version can return None
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Mar 18 15:46:10 2022
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 18 Mar 2022 19:46:10 +0000
Subject: [New-bugs-announce] [issue47061] Document PEP 594 deprecations
Message-ID: <1647632770.65.0.881581261318.issue47061@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

https://peps.python.org/pep-0594/

The SC has asked that all modules deprecated by PEP 594 have the documented deprecation backported. The message should also not have any specific removal version to avoid any potential delay, but then making the bugfix-only docs incorrect.

- [ ] aifc
- [ ] asynchat: https://bugs.python.org/issue47022
- [ ] asyncore: https://bugs.python.org/issue47022
- [ ] audioop
- [ ] cgi
- [ ] cgitb
- [ ] chunk
- [ ] crypt
- [ ] imghdr
- [ ] msilib
- [ ] nntplib
- [ ] nis
- [ ] ossaudiodev
- [ ] pipes
- [ ] smtpd: https://bugs.python.org/issue47022
- [ ] sndhdr
- [ ] spwd
- [ ] sunau
- [ ] telnetlib
- [ ] uu
- [ ] xdrlib

----------
assignee: brett.cannon
components: Library (Lib)
messages: 415521
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PEP 594 deprecations
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 18 16:44:42 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Mar 2022 20:44:42 +0000
Subject: [New-bugs-announce] [issue47062] Implement asyncio.Runner context
 manager
Message-ID: <1647636282.37.0.43859483152.issue47062@roundup.psfhosted.org>


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

Sometimes asyncio.run() is not enough.

For example, unittest test case needs to call several async functions (setup, test, teardown) from the synchronous code using the same execution context and event loop.

The proposal provides the following:

with Runner() as runner:
  runner.run(async_func())

----------
components: asyncio
messages: 415527
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.Runner context manager
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 19 00:25:14 2022
From: report at bugs.python.org (Myron Walker)
Date: Sat, 19 Mar 2022 04:25:14 +0000
Subject: [New-bugs-announce] [issue47063] SimpleHTTPRequestHandler has hard
 coded index page list.
Message-ID: <1647663914.0.0.21035920987.issue47063@roundup.psfhosted.org>


New submission from Myron Walker <myron.walker at gmail.com>:

SimpleHTTPRequestHandler has hard coded index page list in the send_head method.  The fixed hard-coded list means that if you want to have a custom index page that is not named "index.htm" or "index.html" then you have to override the send_head method.  There is alot of code in send_head so overriding it is not optimal just to have a custom indexer filename.

----------
components: Library (Lib)
messages: 415534
nosy: Myron Walker
priority: normal
severity: normal
status: open
title: SimpleHTTPRequestHandler has hard coded index page list.
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Mar 19 05:57:26 2022
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 19 Mar 2022 09:57:26 +0000
Subject: [New-bugs-announce] [issue47064] thread QOS attribute on macOS
Message-ID: <1647683846.62.0.6728584749.issue47064@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Arm based Mac systems have several types of cores: performance cores and efficiency cores.  The system has no way to directly specify which core a particular proces or thread uses, but programs can use an API for setting the QOS class of a thread that will influence which type of core a proces is scheduled on.

The primary use case for this would be to select a lower QOS class for background tasks to ensure that those minimally impact interactive code.

It would be nice to expose this functionality in Python.


One way to do this is to expose two or three new APIs:

0. Expose an enum.IntEnum on macOS for the various QOS classes

1. An API for setting the QOS class of a particular thread (which could also be used to change that class for the main thread), for example a read/write property ``threading.Thread.qos_class``

2. A new keyword argument ``qos_class`` to ``threading.Thread.__init__()``

3. Optional: an API for setting changing the default value for that new keyword argument

The new API would only exist on macOS.

One consideration: This is a platform specific option, in my limited research I haven't found an easy way to accomplish similar results on Linux or Windows.

Background information: https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon

----------
components: Interpreter Core, macOS
messages: 415538
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: thread QOS attribute on macOS
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 19 07:10:26 2022
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 19 Mar 2022 11:10:26 +0000
Subject: [New-bugs-announce] [issue47065] test_curses fails if terminal
 defaults to bright white text (15)
Message-ID: <1647688226.18.0.712110754923.issue47065@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

test_curses fails for me by default (running on Fedora 35 in KDE's Konsole):

```
[ncoghlan at thechalk cpython]$ echo $TERM
xterm-256color
[ncoghlan at thechalk cpython]$ ./python -m test -u curses test_curses
0:00:00 load avg: 0.88 Run tests sequentially
0:00:00 load avg: 0.88 [1/1] test_curses
test test_curses failed -- Traceback (most recent call last):
  File "/home/ncoghlan/devel/cpython/Lib/test/test_curses.py", line 48, in wrapped
    test(self, *args, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ncoghlan/devel/cpython/Lib/test/test_curses.py", line 993, in test_use_default_colors
    self.assertIn(old, [(curses.COLOR_WHITE, curses.COLOR_BLACK), (-1, -1), (0, 0)])
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: (15, 0) not found in [(7, 0), (-1, -1), (0, 0)]

test_curses failed (1 failure)

== Tests result: FAILURE ==

1 test failed:
    test_curses

Total duration: 466 ms
Tests result: FAILURE
```

The active terminal info indicates that the default text colour is indeed bright white (assuming I'm reading the infocmp output correctly), so it feels like (15, 0) is just missing from the set of permissible "old" colour pairs in the test case:

```
[ncoghlan at thechalk cpython]$ infocmp -L | grep initialize_color
        initialize_color=\E]4;%p1%d;rgb\072%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\,
```

----------
components: Tests
messages: 415539
nosy: ncoghlan, petr.viktorin, twouters
priority: normal
severity: normal
stage: needs patch
status: open
title: test_curses fails if terminal defaults to bright white text (15)
type: behavior

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

From report at bugs.python.org  Sat Mar 19 08:09:48 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Mar 2022 12:09:48 +0000
Subject: [New-bugs-announce] [issue47066] Convert a warning about flags not
 at the start of the regular expression into error
Message-ID: <1647691788.19.0.394073158016.issue47066@roundup.psfhosted.org>


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

This warning was introduced in 3.6. The reason is that in most other regular expression implementations global inline flags in the middle of the expression have different semantic: they affect only the part of the expression after the flag. But in Python they affect the whole expression. It caused confusion and was a source of bugs.

After 5 releases it is a time to convert this warning into error. In future we can allow global inline flags in the middle of the expression with different semantic. It is safer if one or more intermediate versions will raise an error.

----------
components: Library (Lib), Regular Expressions
messages: 415544
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert a warning about flags not at the start of the regular expression into error
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 19 11:31:34 2022
From: report at bugs.python.org (penguin_wwy)
Date: Sat, 19 Mar 2022 15:31:34 +0000
Subject: [New-bugs-announce] [issue47067] Add vectorcall for generica alias
 object
Message-ID: <1647703894.62.0.128061572822.issue47067@roundup.psfhosted.org>


New submission from penguin_wwy <940375606 at qq.com>:

Although `ga_call` determines whether `origin` has a vectorcall, it needs to be unpacked the parameters that are already packed.
                                              /-> origin.vectorcall(unpacked)
MakeTpCall(packed) -> ga_call -> PyObject_Call
                                               \-> origin.tp_call

We can advance the `vectorcall` judgment to the `setup` phase.

ga_vectorcall -> origin.vectorcall

or

ga_make_tp_call -> _PyObject_MakeTpCall(packed argument) -> origin.tp_call

This will have no effect on tp_call, which still only needs to be packed once, while vectorcall does not need packed/unpacked

----------
components: Library (Lib)
messages: 415556
nosy: penguin_wwy
priority: normal
severity: normal
status: open
title: Add vectorcall for generica alias object
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 19 13:19:22 2022
From: report at bugs.python.org (Kaleb Barrett)
Date: Sat, 19 Mar 2022 17:19:22 +0000
Subject: [New-bugs-announce] [issue47068] Improve __repr__ of TypeVar
Message-ID: <1647710362.53.0.530954484666.issue47068@roundup.psfhosted.org>


New submission from Kaleb Barrett <dev.ktbarrett at gmail.com>:

Currently the __repr__ for TypeVar includes the variance information and the type name (for example ~T, +T_co, -T_contra), but it does not contain bound or constraint information. I'm not sure what value including variance but not bound information in the __repr__ is, both are important for the use of interfaces that use that variable.

I propose we add the bound and constraint information to the __repr__. The __repr__ is arbitrary as popular type checking tools, such as mypy, and documentation tools, such as Sphinx, do not use the standard __repr__. Nor is the __repr__ eval()-able like many builtin types. And for documentation tools that do use the standard __repr__, this improvement will be propagated to those tools. (I originally requested this improvement in pdoc which uses the standard __repr__; the maintainer agreed with this improvement.)

Bounds can be represented using an ASCII representation of the subset operator "<=" and then the bound. Constraints can be represented using "<=" with a tuple of the constraints. Perhaps spaces should be added around the "<=" operator? I have no opinion.

Some examples of the proposed __repr__:
>>> TypeVar("T")
~T
>>> IntT = TypeVar("IntT", bound=int)
>>> IntT
~IntT<=int
>>> TypeVar("AnyStr", str, bytes)
~AnyStr<=(str, bytes)
>>> List[IntT]
List[~IntT<=int]

----------
messages: 415562
nosy: ktbarrett
priority: normal
severity: normal
status: open
title: Improve __repr__ of TypeVar
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 19 16:18:03 2022
From: report at bugs.python.org (FeRD (Frank Dana))
Date: Sat, 19 Mar 2022 20:18:03 +0000
Subject: [New-bugs-announce] [issue47069] socket._GLOBAL_DEFAULT_TIMEOUT
 being an object() makes for ugly docstrings, can be better
Message-ID: <1647721083.32.0.0857684709094.issue47069@roundup.psfhosted.org>


New submission from FeRD (Frank Dana) <ferdnyc at gmail.com>:

socket._GLOBAL_DEFAULT_TIMEOUT's status as a bare object() instance has been brought up before (bpo-12441). That was reported as a bug, but appeared to stem from developer confusion, so it was correctly closed as "not a bug". At the time @orsenthil defended _GLOBAL_DEFAULT_TIMEOUT's current status quo as:

> The _GLOBAL_DEFAULT_TIMEOUT usage is an established pattern with socket > module. https://github.com/python/cpython/blob/main/Lib/socket.py#L805

I don't disagree with that, but I think it can be improved upon, which is why I'm opening this as an enhancement instead of a bug report.

If nothing else, the current implementation of _GLOBAL_DEFAULT_TIMEOUT makes for some really ugly method synopses, both in socket.py and in other classes that make use of it:

>>> import socket, urllib.request
>>> help(socket.create_connection)
Help on function create_connection in module socket:

create_connection(address, timeout=<object object at 0x7f9986ed8880>, source_address=None)
    Connect to *address* and return the socket object.

>>> help(urllib.request.urlopen)
Help on function urlopen in module urllib.request:

urlopen(url, data=None, timeout=<object object at 0x7f9986ed8880>, *, cafile=None, capath=None, cadefault=False, context=None)
    Open the URL url, which can be either a string or a Request object.

>>>


...Converting socket._GLOBAL_DEFAULT_TIMEOUT from an object() instance to a bare class definition, in the style of an Exception subclass, appears to be semantically equivalent in all cases, but has the advantage that the resulting docstrings become VASTLY more readable:

>>> import myedits; import myedits.socket as socket
>>> help(socket.create_connection)
Help on function create_connection in module myedits.socket:

create_connection(address, timeout=<class 'myedits.socket._GLOBAL_DEFAULT_TIMEOUT'>, source_address=None)
    Connect to *address* and return the socket object.

>>> import sys; sys.modules['socket'] = myedits.socket
>>> import myedits.urllib.request
>>> help(myedits.urllib.request.urlopen)
urlopen(url, data=None, timeout=<class 
Help on function urlopen in module myedits.urllib.request:

urlopen(url, data=None, timeout=<class 'myedits.socket._GLOBAL_DEFAULT_TIMEOUT'>, *, cafile=None, capath=None, cadefault=False, context=None)
    Open the URL url, which can be either a string or a Request object.

>>>


Unless someone objects, I'd like to open a PR changing the definition of  socket._GLOBAL_DEFAULT_TIMEOUT from:

_GLOBAL_DEFAULT_TIMEOUT = object()

to:

class _GLOBAL_DEFAULT_TIMEOUT: pass

While leaving everything else the same. AFAICT from testing, that should have no impact on the functionality of socket or its consumers, but improve life for Python developers by making the module more readable and self-documenting.

----------
components: Library (Lib)
messages: 415568
nosy: ferdnyc
priority: normal
severity: normal
status: open
title: socket._GLOBAL_DEFAULT_TIMEOUT being an object() makes for ugly docstrings, can be better
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 19 17:27:18 2022
From: report at bugs.python.org (Pieter Eendebak)
Date: Sat, 19 Mar 2022 21:27:18 +0000
Subject: [New-bugs-announce] [issue47070] Improve performance of
 array_inplace_repeat
Message-ID: <1647725238.0.0.579298604794.issue47070@roundup.psfhosted.org>


New submission from Pieter Eendebak <pieter.eendebak at gmail.com>:

The array_inplace_repeat is inefficient for small arrays and a high number of repeats. This can be improved by using the same approach as in https://bugs.python.org/issue47005

----------
components: Interpreter Core
messages: 415572
nosy: pieter.eendebak
priority: normal
severity: normal
status: open
title: Improve performance of array_inplace_repeat
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 20 10:58:17 2022
From: report at bugs.python.org (Erik Soma)
Date: Sun, 20 Mar 2022 14:58:17 +0000
Subject: [New-bugs-announce] [issue47071] asyncio proactor udp transport
 stops responding after send to port that isn't listening
Message-ID: <1647788297.71.0.92757207379.issue47071@roundup.psfhosted.org>


New submission from Erik Soma <stillusingirc at gmail.com>:

Reproducer attached. Change `USE_PROACTOR` to `False` to use the `SelectorEventLoop` instead, which doesn't exhibit this behavior.

The output on my machine when using the proactor loop is:
```
datagram received b'ping 1'
datagram received b'ping 2'
```

And the selector loop (which is the behavior I would expect):
```
datagram received b'ping 1'
datagram received b'ping 2'
datagram received b'ping 3'
```


At a high level, after sending data to an address that isn't listening the asyncio protocol will no longer receive messages.


Digging deeper, `_ProactorDatagramTransport._loop_reading` encounters the windows error 1234 (ERROR_PORT_UNREACHABLE) after the "bad send". It appears this a (undocumented/buggy?) behavior of `WSARecvFrom` where the next call to it after an unreachable `WSASendTo` in UDP mode will return the ICMP unreachable message. The actual error is returned from `GetOverlappedResult`.


I've hacked together a fix that retries `IocpProactor.recvfrom` if the result is ERROR_PORT_UNREACHABLE. It fixes the issue for the reproducer and my actual use case, but it's probably not ideal. My solution for the moment is just to use the SelectorEventLoop instead.

----------
components: Windows, asyncio
files: udpbug2.py
messages: 415611
nosy: asvetlov, esoma, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: asyncio proactor udp transport stops responding after send to port that isn't listening
versions: Python 3.10
Added file: https://bugs.python.org/file50691/udpbug2.py

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

From report at bugs.python.org  Sun Mar 20 13:29:23 2022
From: report at bugs.python.org (Hubert Tournier)
Date: Sun, 20 Mar 2022 17:29:23 +0000
Subject: [New-bugs-announce] [issue47072] Database corruption with the
 shelve module
Message-ID: <1647797363.41.0.855477940011.issue47072@roundup.psfhosted.org>


New submission from Hubert Tournier <hubert.tournier at gmail.com>:

After adding a few records, the shelve module corrupts the database keys (the database is still readable if an element key is known, but no more iterable):

Traceback (most recent call last):
  File "./shelve-test.py", line 81, in <module>
    _verify_whois_cache()
  File "./shelve-test.py", line 61, in _verify_whois_cache
    for key in db.keys():
  File "/usr/local/lib/python3.8/_collections_abc.py", line 720, in __iter__
    yield from self._mapping
  File "/usr/local/lib/python3.8/shelve.py", line 95, in __iter__
    for k in self.dict.keys():
SystemError: Negative size passed to PyBytes_FromStringAndSize

I provide a short test program and data that systematically reproduces the bug. I added the a script showing execution messages, the resulting database in DB and text formats.

Tested with Python 3.8.12 on FreeBSD 13.0-RELEASE-p8.
I suppose Python is using my system package db5-5.3.28_8                   (Oracle Berkeley DB, revision 5.3).

See also similar issues:
https://bugs.python.org/issue33074
https://bugs.python.org/issue30388

----------
components: Library (Lib)
files: shelve-test.zip
messages: 415625
nosy: HubTou
priority: normal
severity: normal
status: open
title: Database corruption with the shelve module
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50693/shelve-test.zip

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

From report at bugs.python.org  Sun Mar 20 18:56:45 2022
From: report at bugs.python.org (Yonatan Dankner)
Date: Sun, 20 Mar 2022 22:56:45 +0000
Subject: [New-bugs-announce] [issue47073] Solution for recursion error when
 comparing dataclass objects
Message-ID: <1647817005.88.0.843741930968.issue47073@roundup.psfhosted.org>


New submission from Yonatan Dankner <yonatan.dankner at gmail.com>:

TL;DR: A possible method to avoid infinite recursion when comparing dataclasses with circular references, using a decorator.

>>> @dataclass
... class A:
...     x: int = 1
...     self_reference: Any = field(init=False)
...
...     def __post_init__(self):
...         self.self_reference = self
...
>>> A(x=1) == A(x=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in __eq__
  File "<string>", line 3, in __eq__
  File "<string>", line 3, in __eq__
  [Previous line repeated 330 more times]
RecursionError: maximum recursion depth exceeded in comparison

It should in my opinion return True.

To avoid a recursion error, I would like to suggest a solution using a wrapper, similar to the one implemented for repr (see dataclasses._recursive_repr):
If within the process of comparing two objects, we have encountered an attempt to compare these objects (meaning we have reached a loop), we should return true, since no inequalities will be discovered if we continue recursing.

I suggest an addition to dataclasses.py which would look something like this (drew inspiration from _recursive_repr):

def _recursive_eq(user_function):
    # Decorator to make a eq function return True when a loop was detected.
    eq_running = set()

    @functools.wraps(user_function)
    def wrapper(self, other):
        key = id(self), id(other), _thread.get_ident()
        if key in eq_running:
            return True
        eq_running.add(key)
       
        try:
            result = user_function(self, other)
        finally:
            eq_running.discard(key)
        return result
    return wrapper


# And then replacing the _cmp_fn with the following.

def _cmp_fn(name, op, self_tuple, other_tuple):
    return _recursive_eq(_create_fn(name,
                      ('self', 'other'),
                      [ 'if other.__class__ is self.__class__:',
                       f' return {self_tuple}{op}{other_tuple}',
                        'return NotImplemented']))

I would like to hear your thoughts!

----------
components: Library (Lib)
messages: 415641
nosy: dankner
priority: normal
severity: normal
status: open
title: Solution for recursion error when comparing dataclass objects
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 20 21:46:48 2022
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 21 Mar 2022 01:46:48 +0000
Subject: [New-bugs-announce] [issue47074] Convenient `simplefilter()` in
 `warnings.catch_warnings()`
Message-ID: <1647827208.52.0.288447694179.issue47074@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

Many pytest users would like a concise way to either suppress warnings, or convert them to errors [1].  The current best approach is:

    with warnings.catch_warnings():
        warnings.simplefilter("ignore")  # or "error"

but even this becomes tediously verbose when repeated in hundreds of tests (which I suspect is responsible for many misuses of `pytest.raises()`).  Since these two functions take disjoint arguments [2], I propose allowing catch_warnings() to accept arguments for simplefilter() and forward them on:

    with warnings.catch_warnings("ignore"):  # or "error"

I have a quick implementation at [3] which I can finish if the idea is acceptable.  Although I don't have a concrete use-case for more than the 'action' and 'category' arguments, forwarding all rather than some makes the semantics very simple.

I'd emphasize again that this is very much a convenience-focussed change: I estimate that 95% of all uses will pass only `action="error"` or `action="ignore"`.  Supporting a concise and simple interface for this seems worth the small complication to the design of the warnings module.


[1] see e.g. https://github.com/pytest-dev/pytest/issues/9404 for a long thread
[2] unlike `filterwarnings()`, which has a `module=` argument which would collide with `catch_warnings()`
[3] https://github.com/python/cpython/compare/main...Zac-HD:zac-hd/one-line-catch-warnings

----------
components: Library (Lib)
messages: 415647
nosy: Zac Hatfield-Dodds
priority: normal
severity: normal
status: open
title: Convenient `simplefilter()` in `warnings.catch_warnings()`
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 20 23:01:30 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2022 03:01:30 +0000
Subject: [New-bugs-announce] [issue47075] test_multiprocessing_spawn leaks
 QueueManager dangling processes
Message-ID: <1647831690.39.0.167799487436.issue47075@roundup.psfhosted.org>


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

Apply attached manager_timeout.patch and run the command:

    ./python -m test --fail-env-changed test_multiprocessing_spawn -v -m test_rapid_restart -F -j4

If you fail to reproduce the issue, replace -j4 with -j10 or use a larger number of concurrent jobs.

Output:
---
(...)
0:00:00 load avg: 2.85 Run tests in parallel using 4 child processes
0:00:06 load avg: 3.02 [  1/1] test_multiprocessing_spawn failed (env changed)
test_rapid_restart (test.test_multiprocessing_spawn.WithManagerTestManagerRestart) ... ok

test_rapid_restart (test.test_multiprocessing_spawn.WithProcessesTestManagerRestart) ... ok
Warning -- Dangling processes: {<SpawnProcess name='QueueManager-5' pid=438355 parent=438255 stopped exitcode=-SIGTERM>, <SpawnProcess name='QueueManager-7' pid=438395 parent=438255 stopped exitcode=-SIGTERM>}

test_rapid_restart (test.test_multiprocessing_spawn.WithThreadsTestManagerRestart) ... ok
Warning -- Dangling processes: {<SpawnProcess name='QueueManager-8' pid=438423 parent=438255 stopped exitcode=-SIGTERM>, <SpawnProcess name='QueueManager-9' pid=438456 parent=438255 stopped exitcode=-SIGTERM>}
Warning -- Dangling processes: {<SpawnProcess name='QueueManager-8' pid=438423 parent=438255 stopped exitcode=-SIGTERM>, <SpawnProcess name='QueueManager-9' pid=438456 parent=438255 stopped exitcode=-SIGTERM>}

----------------------------------------------------------------------
Ran 3 tests in 5.404s

OK
Kill <TestWorkerProcess #2 running test=test_multiprocessing_spawn pid=438256 time=6.9 sec> process group
Kill <TestWorkerProcess #3 running test=test_multiprocessing_spawn pid=438259 time=6.9 sec> process group
Kill <TestWorkerProcess #4 running test=test_multiprocessing_spawn pid=438260 time=6.9 sec> process group

== Tests result: ENV CHANGED ==

1 test altered the execution environment:
    test_multiprocessing_spawn

(...)
---


Examples of similar old issues:

* bpo-39932 at https://bugs.python.org/issue39932#msg363925 : <ForkServerProcess(QueueManager-2036, stopped[1])>
* bpo-38447: <SpawnProcess(QueueManager-1576, stopped)>
* bpo-38796: <SpawnProcess name='QueueManager-327' pid=60315 parent=59088 started>
* bpo-34150: <SpawnProcess(QueueManager-181, stopped)>
* bpo-31069 at https://bugs.python.org/issue31069#msg301339 : <ForkServerProcess(QueueManager-465, stopped)>

See also the old fixed bpo-31234 "Make support.threading_cleanup() stricter".

----------
components: Tests
files: manager_timeout.patch
keywords: patch
messages: 415650
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn leaks QueueManager dangling processes
versions: Python 3.11
Added file: https://bugs.python.org/file50694/manager_timeout.patch

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

From report at bugs.python.org  Sun Mar 20 23:14:47 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2022 03:14:47 +0000
Subject: [New-bugs-announce] [issue47076] test_asyncio: test_get_cancelled()
 fails randomly on x86-64 macOS 3.x
Message-ID: <1647832487.19.0.656994824934.issue47076@roundup.psfhosted.org>


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

x86-64 macOS 3.x failures:

* https://buildbot.python.org/all/#/builders/366/builds/2085
* https://buildbot.python.org/all/#/builders/366/builds/2078
* https://buildbot.python.org/all/#/builders/366/builds/2077
* https://buildbot.python.org/all/#/builders/366/builds/2073
* https://buildbot.python.org/all/#/builders/366/builds/2072
* https://buildbot.python.org/all/#/builders/366/builds/2069

Logs:
---
0:18:33 load avg: 2.21 Re-running test_asyncio in verbose mode (matching: test_get_cancelled)
test_get_cancelled (test.test_asyncio.test_queues.QueueGetTests) ... ERROR

======================================================================
ERROR: test_get_cancelled (test.test_asyncio.test_queues.QueueGetTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/asyncio/tasks.py", line 490, in wait_for
    return fut.result()
           ^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/asyncio/queues.py", line 158, in get
    await getter
    ^^^^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/unittest/async_case.py", line 66, in _callTestMethod
    if self._callMaybeAsync(method) is not None:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/unittest/async_case.py", line 93, in _callMaybeAsync
    return self._asyncioTestLoop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/asyncio/base_events.py", line 650, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_asyncio/test_queues.py", line 179, in test_get_cancelled
    self.assertEqual(1, await get_task)
                        ^^^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_asyncio/test_queues.py", line 174, in queue_get
    return await asyncio.wait_for(q.get(), 0.051)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/asyncio/tasks.py", line 492, in wait_for
    raise exceptions.TimeoutError() from exc
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError
---


Recent change related to this test:

commit e707ceb6e464b24ddc9fdbdac7bfe15f7eeb43fd
Author: Andrew Svetlov <andrew.svetlov at gmail.com>
Date:   Wed Mar 16 16:59:12 2022 +0200

    Rewrite asyncio.Queue tests with IsolatedAsyncioTestCace (#31935)

----------
components: Tests, asyncio
messages: 415653
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_get_cancelled() fails randomly on x86-64 macOS 3.x
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 20 23:23:16 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2022 03:23:16 +0000
Subject: [New-bugs-announce] [issue47077] test_asyncio ignores exception in
 _ProactorBasePipeTransport.__del__: RuntimeError('Event loop is closed')
Message-ID: <1647832996.85.0.556447634064.issue47077@roundup.psfhosted.org>


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

AMD64 Windows8.1 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/511/builds/274

Logs (reformatted manually):
---
0:52:04 load avg: 4.31 [147/433/1] test_asyncio failed (env changed) (41 min 6 sec) -- running: test_io (3 min 8 sec)
beginning 6 repetitions
123456
.

Executing <Task pending name='Task-4333' coro=<ConditionTests.test_wait() running at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\test_asyncio\test_locks.py:443> cb=[_run_until_complete_cb() at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py:180] created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\unittest\async_case.py:89> took 0.125 seconds

Executing <Handle BaseProactorEventLoop._loop_self_reading() created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\windows_events.py:320> took 0.141 seconds

..

Executing <Handle BaseProactorEventLoop._loop_self_reading() created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\windows_events.py:320> took 0.110 seconds

D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\inspect.py:3030: ResourceWarning: unclosed <socket.socket fd=1208, family=2, type=1, proto=0, laddr=('127.0.0.1', 59194), raddr=('127.0.0.1', 59195)>
  arg_val = next(arg_vals)

ResourceWarning: Enable tracemalloc to get the object allocation traceback
D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\proactor_events.py:115: ResourceWarning: unclosed transport <_ProactorSocketTransport fd=-1 read=<_OverlappedFuture cancelled>>
  _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)

ResourceWarning: Enable tracemalloc to get the object allocation traceback

Warning -- Unraisable exception
Exception ignored in: <function _ProactorBasePipeTransport.__del__ at 0x000000B403D2FA10>
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\proactor_events.py", line 116, in __del__
    self.close()
    ^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\proactor_events.py", line 108, in close
    self._loop.call_soon(self._call_connection_lost, None)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py", line 758, in call_soon
    self._check_closed()
    ^^^^^^^^^^^^^^^^^^^^
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py", line 519, in _check_closed
    raise RuntimeError('Event loop is closed')
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Event loop is closed

.

Executing <Task pending name='Task-18934' coro=<AsyncioWaitForTest.test_wait_for.<locals>.foo() running at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\test_asyncio\test_waitfor.py:133> wait_for=<Future pending cb=[Task.task_wakeup()] created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py:427> cb=[_release_waiter(<Future pendi...events.py:427>)() at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\tasks.py:421] created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\tasks.py:374> took 0.109 seconds

.

Executing <Task pending name='Task-19641' coro=<SemaphoreTests.test_acquire_hang() running at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\test_asyncio\test_locks.py:899> cb=[_run_until_complete_cb() at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py:180] created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\unittest\async_case.py:89> took 0.125 seconds

Executing <Task pending name='Task-19837' coro=<QueuePutTests.test_get_cancel_drop_many_pending_readers() running at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\test\test_asyncio\test_queues.py:291> wait_for=<Future pending cb=[Task.task_wakeup()] created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py:427> cb=[_run_until_complete_cb() at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py:180] created at D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\unittest\async_case.py:89> took 0.141 seconds

.
---

----------
components: Tests, asyncio
messages: 415657
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio ignores exception in _ProactorBasePipeTransport.__del__: RuntimeError('Event loop is closed')
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 20 23:44:55 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2022 03:44:55 +0000
Subject: [New-bugs-announce] [issue47078] test_ctypes modified files on
 aarch64 Fedora Rawhide 3.9
Message-ID: <1647834295.59.0.927940933477.issue47078@roundup.psfhosted.org>


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

aarch64 Fedora Rawhide 3.9:
https://buildbot.python.org/all/#/builders/245/builds/445

It seems like the "ldconfig" command crashed (signal 11: SIGSEGV).

ldconfig is used by _findSoname_ldconfig() of ctypes.util which runs the "/sbin/ldconfig -p" command with LC_ALL=C and LANG=C env vars.

It looks like a Fedora issue rather than a Python bug.


journalctl:
---
mars 19 20:08:06 python-builder-fedora-rawhide-aarch64 systemd[1]: ldconfig.service - Rebuild Dynamic Linker Cache was skipped because all trigger condition checks failed.
(...)
mars 19 15:50:06 python-builder-fedora-rawhide-aarch64 audit[1587976]: ANOM_ABEND auid=4294967295 uid=1000 gid=1000 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 pid=1587976 comm="ldconfig" exe="/usr/sbin/ldconfig" sig=11 res=1
(...)
mars 19 15:50:06 python-builder-fedora-rawhide-aarch64 audit[1587976]: ANOM_ABEND auid=4294967295 uid=1000 gid=1000 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 pid=1587976 comm="ldconfig" exe="/usr/sbin/ldconfig" sig=11 res=1
(...)
mars 19 01:02:52 python-builder-fedora-rawhide-aarch64 audit[512983]: ANOM_ABEND auid=4294967295 uid=1000 gid=1000 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 pid=512983 comm="ldconfig" exe="/usr/sbin/ldconfig" sig=11 res=1
(...)
mars 18 19:33:00 python-builder-fedora-rawhide-aarch64 systemd[1]: ldconfig.service - Rebuild Dynamic Linker Cache was skipped because all trigger condition checks failed.
---

configure:
---
checking for --with-system-ffi... yes
---

test.pythoninfo:
---
CC.version: gcc (GCC) 12.0.1 20220308 (Red Hat 12.0.1-0)
---

Logs:
---
0:00:18 load avg: 12.24 [241/425/1] test_ctypes failed (env changed)
Warning -- files was modified by test_ctypes
test_anon (ctypes.test.test_anon.AnonTest) ... ok
(...)
test_variant_bool (ctypes.test.test_wintypes.WinTypesTest) ... ok

----------------------------------------------------------------------
Ran 494 tests in 1.350s

OK (skipped=88)
  Before: []
  After:  ['.1587976']

1 test altered the execution environment:
    test_ctypes
---

----------
components: Tests
messages: 415658
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_ctypes modified files on aarch64 Fedora Rawhide 3.9
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 20 23:48:09 2022
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Mon, 21 Mar 2022 03:48:09 +0000
Subject: [New-bugs-announce] [issue47079] Integral.denominator shouldn't
 return an int
Message-ID: <1647834489.3.0.839455374246.issue47079@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

As the __int__() method is required, I believe it can return self(1) instead.

Also, probably +self normalization could be avoided in the Integral.numerator().

----------
components: Library (Lib)
messages: 415660
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Integral.denominator shouldn't return an int
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 00:03:21 2022
From: report at bugs.python.org (Tim Peters)
Date: Mon, 21 Mar 2022 04:03:21 +0000
Subject: [New-bugs-announce] [issue47080] Use atomic groups to simplify
 fnmatch
Message-ID: <1647835401.09.0.198463274654.issue47080@roundup.psfhosted.org>


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

I added some excruciatingly obscure technical tricks to ensure that fnmatch.py's regexps can't fall into exponential-time match failures.

It's hard to stop re from useless backtracking. But the new "atomic groups" make that easy instead in some cases, and make it trivial in the cases fnmatch needs.

Of course addressing this has to wait for the atomic groups PR to get merged GH-31982)

----------
assignee: tim.peters
components: Library (Lib)
messages: 415662
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Use atomic groups to simplify fnmatch
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 12:39:01 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Mar 2022 16:39:01 +0000
Subject: [New-bugs-announce] [issue47081] Replace "qualifiers" with
 "quantifiers" in the re module documentation
Message-ID: <1647880741.05.0.407746154875.issue47081@roundup.psfhosted.org>


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

In the Web you can find that two terms are used for repetition operators (+, *, ?, and variants): "quantifiers" and "qualifiers". "Quantifiers" is much more common, it is used in Wikipedia and main on-line documentation resources. But "qualifiers" is consistently used in the re module code documentation.

It looks to me that "qualifiers" is just a reproduced typo. I propose to replace it with "quantifiers".

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 415686
nosy: docs at python, ezio.melotti, mrabarnett, serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: Replace "qualifiers" with "quantifiers" in the re module documentation
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 13:03:05 2022
From: report at bugs.python.org (Jens Henrik Goebbert)
Date: Mon, 21 Mar 2022 17:03:05 +0000
Subject: [New-bugs-announce] [issue47082] No protection: `import numpy` in
 two different threads can lead to race-condition
Message-ID: <1647882185.36.0.953866126148.issue47082@roundup.psfhosted.org>


New submission from Jens Henrik Goebbert <j.goebbert at fz-juelich.de>:

While using [Xpra](https://github.com/Xpra-org/xpra) we came across a bug which might be a Python or a NumPy issue.
Perhaps some of you can help us understanding some internals.

Calling `import numpy` at the same time in two different threads of the Python program can lead to a race-condition.
This happens for example with Xpra when loading the encoder nvjpeg:
```
2022-03-20 12:54:59,298  cannot load enc_nvjpeg (nvjpeg encoder)
Traceback (most recent call last):
  File "<pythondir>/lib/python3.9/site-packages/xpra/codecs/loader.py", line 52, in codec_import_check
    ic =  __import__(class_module, {}, {}, classnames)
  File "xpra/codecs/nvjpeg/encoder.pyx", line 8, in init xpra.codecs.nvjpeg.encoder
  File "<pythondir>/lib/python3.9/site-packages/numpy/__init__.py", line 150, in <module>
    from . import core
  File "<pythondir>/lib/python3.9/site-packages/numpy/core/__init__.py", line 51, in <module>
    del os.environ[envkey]
  File "<pythondir>/lib/python3.9/os.py", line 695, in __delitem__
    raise KeyError(key) from None
KeyError: 'OPENBLAS_MAIN_FREE'
```

Here the environment variable OPENBLAS_MAIN_FREE is set in the `numpy` code:
https://github.com/numpy/numpy/blob/maintenance/1.21.x/numpy/core/__init__.py#L18
and short after that it is deleted
https://github.com/numpy/numpy/blob/maintenance/1.21.x/numpy/core/__init__.py#L51
But this deletion fails ... perhaps because the initialization runs at the same time in two threads :thinking:

Shouldn't Python protect us by design?

@seberg comments [HERE](https://github.com/numpy/numpy/issues/21223#issuecomment-1074008386):
```
So, my current hypothesis (and I have briefly checked the Python code) is that Python does not do manual locking. But it effectively locks due to this going into C and thus holding the GIL. But somewhere during the import of NumPy, NumPy probably releases the GIL briefly and that could allow the next thread to go into the import machinery.
[..]
NumPy may be doing some worse than typical stuff here, but right now it seems to me that Python should be protecting us.
```

Can anyone comment on this?

----------
components: Interpreter Core
messages: 415687
nosy: jhgoebbert
priority: normal
severity: normal
status: open
title: No protection: `import numpy` in two different threads can lead to race-condition
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 13:09:40 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 21 Mar 2022 17:09:40 +0000
Subject: [New-bugs-announce] [issue47083] The __complex__ method is missing
 from the complex, float, and int built-in types
Message-ID: <1647882580.13.0.610930198027.issue47083@roundup.psfhosted.org>


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

## Expected outcome

```
>>> hasattr(complex(), '__complex__')
True
>>> hasattr(float(), '__complex__')
True
>>> hasattr(int(), '__complex__')
True
```

## Actual outcome

```
>>> hasattr(complex(), '__complex__')
False
>>> hasattr(float(), '__complex__')
False
>>> hasattr(int(), '__complex__')
False
```

## Rationale

The `numbers.Complex` abstract base class has a `__complex__` abstract method and the `numbers.Real` and `numbers.Integral` abstract base classes inherit from `numbers.Complex` (https://github.com/python/cpython/blob/v3.10.3/Lib/numbers.py#L45-L47):

```
    @abstractmethod
    def __complex__(self):
        """Return a builtin complex instance. Called for complex(self)."""
```

The `complex` built-in type is a virtual subclass (nominal subtype) of `numbers.Complex` (https://github.com/python/cpython/blob/v3.10.3/Lib/numbers.py#L144):

```
Complex.register(complex)
```

The `float` built-in type is a virtual subclass (nominal subtype) of `numbers.Real` (https://github.com/python/cpython/blob/v3.10.3/Lib/numbers.py#L264):

```
Real.register(float)
```

The `int` built-in type is a virtual subclass (nominal subtype) of `numbers.Integral` (https://github.com/python/cpython/blob/v3.10.3/Lib/numbers.py#L393):

```
Integral.register(int)
```

`__complex__` is the only method of the abstract base classes of `numbers` missing from `complex`, `float`, and `int`:

```
>>> import numbers
>>> for attr in dir(numbers.Complex):
...     if not hasattr(complex(), attr): print(attr)
... 
__abstractmethods__
__complex__
__module__
__slots__
_abc_impl
>>> for attr in dir(numbers.Real):
...     if not hasattr(float(), attr): print(attr)
... 
__abstractmethods__
__complex__
__module__
__slots__
_abc_impl
>>> for attr in dir(numbers.Integral):
...     if not hasattr(int(), attr): print(attr)
... 
__abstractmethods__
__complex__
__module__
__slots__
_abc_impl
```

----------
components: Interpreter Core
messages: 415689
nosy: maggyero
priority: normal
severity: normal
status: open
title: The __complex__ method is missing from the complex, float, and int built-in types
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon Mar 21 14:37:52 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 21 Mar 2022 18:37:52 +0000
Subject: [New-bugs-announce] [issue47084] Statically allocated Unicode
 objects leak cached representations
Message-ID: <1647887872.48.0.319313487677.issue47084@roundup.psfhosted.org>


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

The newly implemented statically allocated Unicode objects do not clear their cached representations (wstr and utf-8) at exit causing leaked blocks at exit (see also issue46857).

At issue are the Unicode objects created by deepfreeze and the 1-character strings (ordinals < 256).

----------
components: Interpreter Core, Unicode
messages: 415695
nosy: ezio.melotti, jkloth, vstinner
priority: normal
severity: normal
status: open
title: Statically allocated Unicode objects leak cached representations
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 15:21:07 2022
From: report at bugs.python.org (Thomas Grainger)
Date: Mon, 21 Mar 2022 19:21:07 +0000
Subject: [New-bugs-announce] [issue47085] missing frame.f_lineno on
 JUMP_ABSOLUTE
Message-ID: <1647890467.59.0.144255905293.issue47085@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

the following code prints:

import sys
import dis

import pprint

def demo():
    for i in range(1):
        if i >= 0:
            pass


class Tracer:
    def __init__(self):
        self.events = []

    def trace(self, frame, event, arg):
        self.events.append((frame.f_lineno, frame.f_lasti, event))
        frame.f_trace_lines = True
        frame.f_trace_opcodes = True
        return self.trace

def main():
    t = Tracer()
    old_trace = sys.gettrace()
    try:
        sys.settrace(t.trace)
        demo()
    finally:
        sys.settrace(old_trace)
    dis.dis(demo)
    pprint.pp(t.events)


if __name__ == "__main__":
    sys.exit(main())



  7           0 LOAD_GLOBAL              0 (range)
              2 LOAD_CONST               1 (1)
              4 CALL_FUNCTION            1
              6 GET_ITER
        >>    8 FOR_ITER                 7 (to 24)
             10 STORE_FAST               0 (i)

  8          12 LOAD_FAST                0 (i)
             14 LOAD_CONST               2 (0)
             16 COMPARE_OP               5 (>=)
             18 POP_JUMP_IF_FALSE       11 (to 22)

  9          20 NOP
        >>   22 JUMP_ABSOLUTE            4 (to 8)

  7     >>   24 LOAD_CONST               0 (None)
             26 RETURN_VALUE
[(6, -1, 'call'),
 (7, 0, 'line'),
 (7, 0, 'opcode'),
 (7, 2, 'opcode'),
 (7, 4, 'opcode'),
 (7, 6, 'opcode'),
 (7, 8, 'opcode'),
 (7, 10, 'opcode'),
 (8, 12, 'line'),
 (8, 12, 'opcode'),
 (8, 14, 'opcode'),
 (8, 16, 'opcode'),
 (8, 18, 'opcode'),
 (9, 20, 'line'),
 (9, 20, 'opcode'),
 (None, 22, 'opcode'),
 (7, 8, 'line'),
 (7, 8, 'opcode'),
 (7, 24, 'opcode'),
 (7, 26, 'opcode'),
 (7, 26, 'return')]


but I'd expect  (9, 22, 'opcode') instead of (None, 22, 'opcode'),

----------
messages: 415697
nosy: graingert
priority: normal
severity: normal
status: open
title: missing frame.f_lineno on JUMP_ABSOLUTE
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon Mar 21 16:44:27 2022
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Mar 2022 20:44:27 +0000
Subject: [New-bugs-announce] [issue47086] Include HTML docs with Windows
 installer instead of CHM
Message-ID: <1647895467.15.0.262740813559.issue47086@roundup.psfhosted.org>


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

CHM is getting too hard to handle (see e.g. issue47051 for the latest issue), so let's just bite the bullet and ship the HTML docs instead.

----------
components: Windows
messages: 415701
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Include HTML docs with Windows installer instead of CHM
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 17:18:31 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Mar 2022 21:18:31 +0000
Subject: [New-bugs-announce] [issue47087] Implement PEP 655
 (Required/NotRequired)
Message-ID: <1647897511.2.0.22546468537.issue47087@roundup.psfhosted.org>


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

PEP 655 was just accepted, so we should implement it in typing.py! We should be able to largely reuse the typing-extensions implementation.

(I can't find David Foster on BPO but I'll point him to this issue.)

----------
messages: 415704
nosy: AlexWaygood, JelleZijlstra, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Implement PEP 655 (Required/NotRequired)

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

From report at bugs.python.org  Mon Mar 21 17:24:35 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 21 Mar 2022 21:24:35 +0000
Subject: [New-bugs-announce] [issue47088] Implement PEP 675 (LiteralString)
Message-ID: <1647897875.4.0.562368830483.issue47088@roundup.psfhosted.org>


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

This one should be quite simple at runtime. I'll send a PR this week.

----------
assignee: JelleZijlstra
messages: 415706
nosy: AlexWaygood, JelleZijlstra, gvanrossum, kj
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement PEP 675 (LiteralString)
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 21 17:34:06 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 21 Mar 2022 21:34:06 +0000
Subject: [New-bugs-announce] [issue47089] Avoid sporadic failure of
 test_compileall on Windows
Message-ID: <1647898446.37.0.407539254542.issue47089@roundup.psfhosted.org>


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

Testing on Windows occasionally has issues in test_compileall when running with multiple processes.  This is due to other test files importing stdlib modules at the same time that compileall is doing its own testing.  While not fatal (test_compileall succeeds on re-run), the transient warnings obfuscate the test results for other "real" warnings (e.g., compiler warnings) without digging into each run separately.

This can be avoided by using the PYTHONPYCACHEPREFIX functionality to compile the stdlib modules locally.

----------
components: Tests
messages: 415711
nosy: jkloth
priority: normal
severity: normal
status: open
title: Avoid sporadic failure of test_compileall on Windows
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Mar 22 04:38:53 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 22 Mar 2022 08:38:53 +0000
Subject: [New-bugs-announce] [issue47090] Make zlib required on all
 platforms (simplifies code)
Message-ID: <1647938333.52.0.126058309361.issue47090@roundup.psfhosted.org>


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

We have a pile of conditionals and extra code in CPython to deal with building on systems that do not have zlib.  The zlib C library has been around forever at this point and should be present on every system in the world.

zlib is already required on Windows to build CPython.

Proposal: simplify our code by removing the conditionals around zlib being optional.  I'm attaching a draft PR to show what this would look like.

----------
assignee: gregory.p.smith
components: Build, Extension Modules, Library (Lib)
messages: 415750
nosy: gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Make zlib required on all platforms (simplifies code)
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 22 08:37:50 2022
From: report at bugs.python.org (Pieter Eendebak)
Date: Tue, 22 Mar 2022 12:37:50 +0000
Subject: [New-bugs-announce] [issue47091] Improve performance of list and
 tuple repeat methods
Message-ID: <1647952670.83.0.274983393245.issue47091@roundup.psfhosted.org>


New submission from Pieter Eendebak <pieter.eendebak at gmail.com>:

Approach is similar to https://github.com/python/cpython/pull/31856 and https://github.com/python/cpython/pull/31999

----------
components: Interpreter Core
messages: 415762
nosy: pieter.eendebak
priority: normal
severity: normal
status: open
title: Improve performance of list and tuple repeat methods
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 22 10:41:38 2022
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Mar 2022 14:41:38 +0000
Subject: [New-bugs-announce] [issue47092] [C API] Add PyFrame_GetVar(frame,
 name) function
Message-ID: <1647960098.17.0.347400705187.issue47092@roundup.psfhosted.org>


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

In Python 3.10, it's possible to call PyFrame_FastToLocalsWithError() on a frame to get all variables as a dictionary. In Python, getting frame.f_locals calls PyFrame_FastToLocalsWithError(). It's used by the pdb module for example:

    self.curframe_locals = self.curframe.f_locals

The PyFrame_FastToLocalsWithError() function has multiple issues:

* It's inefficient.
* It may create a Python dictionary.
* It can fail to add items to the dictionary.
* Allocating memory can fail with memory allocation failure.

The problem is that a debugger or profiler should not modify a process when it inspects it. It should avoid allocation memory for example. I propose adding a new API to prevent that.

In Python 3.11, the PyFrameObject structure became opaque and changed deeply. There are differend kinds of variables stored differently:

* Free variables: maybe in frame->f_func->func_closure[index], maybe in frame->localsplus[index]
* Fast variable: frame->f_frame->localsplus[index]
* Cell variable: also need to call PyCell_GET()

Well... Look at _PyFrame_FastToLocalsWithError(), it's quite complicated ;-)

I propose to add a new public C API just to get a single variable value:

  PyObject* PyFrame_GetVar(PyFrameObject *frame, PyObject *name)

I prefer to use a PyObject* for the name. You can use PyUnicode_FromString() to get a PyObject* from a const char*.

This function would get the value where the variable is stored, it doesn't have a to create a dictionary. Return NULL if the variable doesn't exist.

If I understand correctly, it should be possible to ensure that this function would never raise an exception (never "fail"). So it should be possible to call it even if an exception is raised, which is convenient for a debugger.

--

I plan to implement this API, but first I would like to make sure that there is an agreement that such API is needed and helpful ;-)

--

See also draft PEP 558 and PEP 667 which propose API to *modify* variables and make sure that they remain consistent when they are set and then get. The scope of these PEPs is way wider than the simple propose PyFrame_GetVar() which would be simpler implementation than PyFrame_FastToLocalsWithError().

----------
components: C API
messages: 415776
nosy: Mark.Shannon, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: [C API] Add PyFrame_GetVar(frame, name) function
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 22 10:57:34 2022
From: report at bugs.python.org (J Y)
Date: Tue, 22 Mar 2022 14:57:34 +0000
Subject: [New-bugs-announce] [issue47093] Documentation Fix: Remove .bat
 when activating venv on windows
Message-ID: <1647961054.99.0.629275554112.issue47093@roundup.psfhosted.org>


New submission from J Y <jovinator77 at gmail.com>:

https://docs.python.org/3/tutorial/venv.html

For windows, tutorial-env\Scripts\activate.bat doesn't appear to set up venv successfully. 

Instead, tutorial-env\Scripts\activate (without .bat) works. This may confuse new users if this is not rectified.

----------
assignee: docs at python
components: Documentation
messages: 415783
nosy: docs at python, jovinator
priority: normal
severity: normal
status: open
title: Documentation Fix: Remove .bat when activating venv on windows
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 22 11:09:35 2022
From: report at bugs.python.org (Tk44)
Date: Tue, 22 Mar 2022 15:09:35 +0000
Subject: [New-bugs-announce] [issue47094] index doesn't change while looping
 through same elements in a list
Message-ID: <1647961775.52.0.996797054137.issue47094@roundup.psfhosted.org>


New submission from Tk44 <tugberk at gmail.com>:

Let us define a list where there are some duplicate elements. If we loop through that list as "for i in my_list" and print the index by my_list.index(i); the index doesn't change.

e.g.

my_list = [1,1,1,1,3]
for elm in my_list:
   print(my_list.index(elm))

==output==
0
0
0
0
4

This occurs where elements are of type string as well. Of course this can be overcome by using enumerate(); however I think this is a wrong behavior.

----------
messages: 415785
nosy: Tugberk
priority: normal
severity: normal
status: open
title: index doesn't change while looping through same elements in a list
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar 22 15:51:17 2022
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 22 Mar 2022 19:51:17 +0000
Subject: [New-bugs-announce] [issue47095] Deprecate blake2's tree hashing
 feature
Message-ID: <1647978677.39.0.283744368692.issue47095@roundup.psfhosted.org>


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

Python's blake2 implementation provides hashing, MAC (key, salt, personalization), variable length output, and tree hashing [1]. All features except for tree hashing are provided by OpenSSL 3.0.0 and newer [2]. It is unlikely that OpenSSL will get tree hashing any time soon, if all. [3]

I would like to remove our vendored copy of blake2 eventually and just rely on OpenSSL. Therefore I propose to deprecate tree hashing feature so we can drop it in Python 3.13. The tree hashing parameters are: fanout, depth, leaf_size, node_offset, node_depth, inner_size, last_node

Note: OpenSSL 3.0 might impose additional restrictions on the parameter. It might be possible that OpenSSL does not support salt and personalization (OSSL_MAC_PARAM_CUSTOM) without a MAC key.

Alternatively we could replace our copy of blake2 and depend on libb2 from https://blake2.net/. libb2 is available in Fedora.

[1] https://docs.python.org/3/library/hashlib.html#hashlib.blake2b
[2] https://www.openssl.org/docs/manmaster/man7/EVP_MAC-BLAKE2.html
[3] https://github.com/openssl/openssl/issues/980

----------
components: Extension Modules
messages: 415807
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: Deprecate blake2's tree hashing feature
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 22 15:51:28 2022
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 22 Mar 2022 19:51:28 +0000
Subject: [New-bugs-announce] [issue47096] Use the PDH API in
 WindowsLoadTracker
Message-ID: <1647978688.65.0.802147114053.issue47096@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

In bpo-44336, a new version of WindowsLoadTracker was implemented in Lib/test/libregrtest/win_utils.py. This version resolves issues with the previous implementation that spawned typeperf.exe. The new implementation uses the registry API's HKEY_PERFORMANCE_DATA pseudohandle to access the performance counters. This requires hard-coding "2" as the key name of the system object, 44 as the index of the "Processor Queue Length" counter, and also several struct definitions. 

The HKEY_PERFORMANCE_DATA 'key' just wraps the API as an alternate way to consume counter data. Instead of taking this detour through a minimalist interface just to use the API in a roundabout way, it would be better to implement a few of the Performance Data Helper functions in _winapi. I've implemented a prototype in ctypes to demonstrate this, which I'm attaching as "loadtracker.py". The functions that would need to be implemented are PdhOpenQueryW(), PdhAddEnglishCounterW(), PdhCollectQueryData(), PdhGetRawCounterValue(), and PdhCloseQuery().

----------
components: Windows
files: loadtracker.py
messages: 415808
nosy: eryksun, jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Use the PDH API in WindowsLoadTracker
type: enhancement
Added file: https://bugs.python.org/file50696/loadtracker.py

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

From report at bugs.python.org  Tue Mar 22 22:08:36 2022
From: report at bugs.python.org (Jelle Zijlstra)
Date: Wed, 23 Mar 2022 02:08:36 +0000
Subject: [New-bugs-announce] [issue47097] Document PEP 646
Message-ID: <1648001316.99.0.843695739634.issue47097@roundup.psfhosted.org>


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

https://docs.python.org/3.11/library/typing.html doesn't say anything about TypeVarTuple yet.

----------
assignee: docs at python
components: Documentation
messages: 415850
nosy: AlexWaygood, JelleZijlstra, docs at python, gvanrossum, kj, mrahtz
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 646
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 23 05:06:22 2022
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 23 Mar 2022 09:06:22 +0000
Subject: [New-bugs-announce] [issue47098] sha3: Replace Keccak Code Package
 with tiny_sha3
Message-ID: <1648026382.03.0.0255347692375.issue47098@roundup.psfhosted.org>


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

The Keccak Code Package (kcp) provides the reference implementation for SHA3 and SHAKE hashing algorithms. CPython has vendored a copy of KCP since I added SHA3 in 3.6.

CPython 3.10 and newer require OpenSSL >= 1.1.1, which provide an optimized implementation of SHA3 and SHAKE on all platforms. The vast majority of users now use SHA3 from OpenSSL instead our _sha3 module with KCP. Both the KCP and _sha3 module are large. The KCP has 230kB of code. The _sha3 shared library is 390kB on Linux X86_64, stripped 90kB.

I would like to reduce the size of our bundled code. Since SHA3 and SHAKE are listed in hashlib.algorithms_guaranteed and OpenSSL is optional, we cannot just drop the _sha3 module. Instead I propose to replace the implementation with tiny_sha3 https://github.com/mjosaarinen/tiny_sha3 . The tiny implementation is 13 kB of code. The resulting _sha3 shared library is 69 kB (stripped 25 kB).

A Python build without OpenSSL bindings will have a working but slower SHA3 implementation.

----------
assignee: christian.heimes
components: Extension Modules
messages: 415861
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: sha3: Replace Keccak Code Package with tiny_sha3
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 23 06:42:51 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Wed, 23 Mar 2022 10:42:51 +0000
Subject: [New-bugs-announce] [issue47099] Replace with_traceback() with
 exception chaining and reraising
Message-ID: <1648032171.38.0.470876447666.issue47099@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

Currently, exception chaining in Lib/ modules is implemented with pre-3.11 `raise Foo(...).with_traceback(sys.exc_info()[2])`. However, this approach can be simplified:

1. PEP 3134 introduced a proper `raise Foo(...) from bar` construction that takes a parent exception instead of its stack traceback

2. Without the traceback required, we partially get rid of `sys.exc_info` thus reducing active tapping into global internals

A report printed into a console remains the same except a line:

> During handling of the above exception, another exception occurred

replaced with:

> The above exception was the direct cause of the following exception

----------
components: Library (Lib)
messages: 415864
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Replace with_traceback() with exception chaining and reraising
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 23 08:20:46 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 23 Mar 2022 12:20:46 +0000
Subject: [New-bugs-announce] [issue47100] Help text for Store Python shows
 "null" under usage
Message-ID: <1648038046.56.0.527997559896.issue47100@roundup.psfhosted.org>


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

C:\> python3.11 -h                                         
usage: (null) [option] ... [-c cmd | -m mod | file | -] [arg] ...  
Options and arguments (and corresponding environment variables):   
...

Should not show "(null)" there

----------
components: Windows
messages: 415869
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Help text for Store Python shows "null" under usage
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Mar 23 10:28:49 2022
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 23 Mar 2022 14:28:49 +0000
Subject: [New-bugs-announce] [issue47101] hashlib.algorithms_available lists
 algorithms that are not available in OpenSSL 3.0 default provider
Message-ID: <1648045729.74.0.801918248822.issue47101@roundup.psfhosted.org>


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

Hubert Kario wrote in https://bugzilla.redhat.com/show_bug.cgi?id=2054702

Description of problem:
The hashlib.algorithms_available set includes algorithms like ripemd160 and whirlpool, those algorithms are not usable unless openssl legacy provider is loaded. Since it's not loaded, and the hashlib module won't load it, any attempt to use them fails.

Version-Release number of selected component (if applicable):
python3-3.9.10-1.el9.x86_64
openssl-3.0.1-5.el9.x86_64

How reproducible:
always

Steps to Reproduce:
0. start python3
1. from hashlib import algorithms_available 
2. algorithms_available
3. import hashlib
4. a = {(name, hashlib.new(name).digest_size) for name in algorithms_available}

Actual results:
{'sha3_384', 'blake2s', 'sha384', 'sha512_224', 'md5', 'sha3_512', 'md5-sha1', 'sha3_256', 'shake_128', 'sm3', 'sha256', 'sha512', 'sha1', 'shake_256', 'blake2b', 'whirlpool', 'sha512_256', 'sha3_224', 'sha224', 'ripemd160', 'md4'}

Traceback (most recent call last):
  File "/usr/lib64/python3.9/hashlib.py", line 164, in __hash_new
    return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines] unsupported

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <setcomp>
  File "/usr/lib64/python3.9/hashlib.py", line 170, in __hash_new
    return __get_builtin_constructor(name)(data)
  File "/usr/lib64/python3.9/hashlib.py", line 127, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type whirlpool


Expected results:
{'sha3_384', 'blake2s', 'sha384', 'sha512_224', 'md5', 'sha3_512', 'md5-sha1', 'sha3_256', 'shake_128', 'sm3', 'sha256', 'sha512', 'sha1', 'shake_256', 'blake2b', 'sha512_256', 'sha3_224', 'sha224'}

{('blake2b', 64), ('sha512', 64), ('md5-sha1', 36), ('sha3_512', 64), ('md5', 16), ('sha224', 28), ('shake_128', 0), ('sm3', 32), ('blake2s', 32), ('sha1', 20), ('shake_256', 0), ('sha512_256', 32), ('sha3_224', 28), ('sha3_256', 32), ('sha3_384', 48), ('sha384', 48), ('sha256', 32), ('sha512_224', 28)}

Additional info:
If the legacy provider is loaded, then the algorithms should be listed and should work.

It may be caused by Python using the deprecated EVP_MD_do_all() method instead of the EVP_MD_do_all_provided() method

----------
components: Extension Modules, Library (Lib)
messages: 415877
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: hashlib.algorithms_available lists algorithms that are not available in OpenSSL 3.0 default provider
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Wed Mar 23 15:30:13 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 23 Mar 2022 19:30:13 +0000
Subject: [New-bugs-announce] [issue47102] explore hashlib use of the Linux
 Kernel CryptoAPI
Message-ID: <1648063813.11.0.72255294176.issue47102@roundup.psfhosted.org>


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

Linux kernels provide a CryptoAPI. This is a common place for platform specific hardware accelerated hash algorithms to be exposed to the user (especially on SoCs which often have non-standard hardware).

https://www.kernel.org/doc/html/v4.10/crypto/userspace-if.html
https://www.kernel.org/doc/html/v5.17/crypto/userspace-if.html
https://www.chronox.de/libkcapi.html

hashlib currently uses OpenSSL when possible for performance.  We could also look at querying the kernel API.  How to decide between the two implementations when both are present is something TBD.

This would probably be best done via a configure time check for libkcapi?

----------
messages: 415896
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: explore hashlib use of the Linux Kernel CryptoAPI
type: enhancement

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

From report at bugs.python.org  Wed Mar 23 16:00:21 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 23 Mar 2022 20:00:21 +0000
Subject: [New-bugs-announce] [issue47103] Copy pgort140.dll when building
 for PGO
Message-ID: <1648065621.85.0.817743953237.issue47103@roundup.psfhosted.org>


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

Rather than trying to set up PATH properly, we should just copy pgort140.dll into the build directory when building instrumented version.

This becomes more important for those (i.e. me) building and then manually running the profile stage on a different machine.

----------
assignee: steve.dower
components: Build, Windows
messages: 415905
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Copy pgort140.dll when building for PGO
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 23 16:42:40 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Mar 2022 20:42:40 +0000
Subject: [New-bugs-announce] [issue47104] Rewrite asyncio.to_thread tests to
 use IsolatedAsyncioTestCase
Message-ID: <1648068160.16.0.895726733187.issue47104@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: Tests, asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Rewrite asyncio.to_thread tests to use IsolatedAsyncioTestCase
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu Mar 24 01:00:10 2022
From: report at bugs.python.org (Alex Hedges)
Date: Thu, 24 Mar 2022 05:00:10 +0000
Subject: [New-bugs-announce] [issue47105] [Doc] grp cites pwd.h instead of
 grp.h
Message-ID: <1648098010.35.0.616040539992.issue47105@roundup.psfhosted.org>


New submission from Alex Hedges <aphedges1 at gmail.com>:

The documentation page for the grp module says to "see <pwd.h>", even though the source code (https://github.com/python/cpython/blob/v3.11.0a6/Modules/grpmodule.c) uses grp.h.

I plan to release a PR for this shortly.

----------
assignee: docs at python
components: Documentation
messages: 415924
nosy: aphedges, docs at python
priority: normal
severity: normal
status: open
title: [Doc] grp cites pwd.h instead of grp.h
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 24 03:42:08 2022
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Mar 2022 07:42:08 +0000
Subject: [New-bugs-announce] [issue47106] test_asyncio:
 test_shutdown_cleanly() failed with timeout (10 seconds) on slow x86 Gentoo
 Non-Debug with X 3.x
Message-ID: <1648107728.15.0.548883065453.issue47106@roundup.psfhosted.org>


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

test_shutdown_cleanly() of test_asyncio failed on x86 Gentoo Non-Debug with X 3.x with a timeout of 10 seconds:
https://buildbot.python.org/all/#/builders/58/builds/1958

asyncio uses a default timeout of 60 seconds for a TLS handshake, but the test takes makes 6x shorter: use a timeout of 10 seconds, I'm not sure why.

To support slow buildbots, I would suggest to use *longer* timeout than the default, not *shorter* timeouts.

test_ssl uses various values for the TLS timeout:

* 1.0 second
* 10.0 seconds
* 40.0 seconds
* 60.0 seconds

Would it be possible to make these values more consistent?

You may want to use on of test.support timeout which has a value depending on regrtest --timeout parameter: on slow buildbots, these values are larger.

* LOOPBACK_TIMEOUT
* SHORT_TIMEOUT
* LONG_TIMEOUT
* INTERNET_TIMEOUT
* Documentation: https://docs.python.org/dev/library/test.html#test.support.LOOPBACK_TIMEOUT

I would recommend using SHORT_TIMEOUT.

x86 Gentoo Non-Debug with X 3.x uses "--timeout=2100" option:

"0:00:00 load avg: 2.89 Run tests in parallel using 2 child processes (timeout: 35 min, worker timeout: 40 min)"


Logs:

0:35:34 load avg: 3.13 Re-running test_asyncio in verbose mode (matching: test_shutdown_cleanly)
test_shutdown_cleanly (test.test_asyncio.test_ssl.TestSSL) ... Warning -- Uncaught thread exception: AssertionError
Exception in thread test-server:
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1706, in _run
    self._handle_client(conn)
    ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1717, in _handle_client
    self._prog(TestSocketWrapper(sock))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1183, in server
    sock.unwrap()
    ^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/ssl.py", line 1321, in unwrap
    s = self._sslobj.shutdown()
        ^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: The read operation timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/threading.py", line 1031, in _bootstrap_inner
    self.run()
    ^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1675, in run
    self._run()
    ^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1714, in _run
    self._test._abort_socket_test(ex)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 163, in _abort_socket_test
    self.fail(ex)
    ^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/unittest/case.py", line 671, in fail
    raise self.failureException(msg)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: The read operation timed out
ERROR

Stderr:
/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/threading.py:1033: ResourceWarning: unclosed <ssl.SSLSocket fd=9, family=2, type=1, proto=0, laddr=('127.0.0.1', 51261), raddr=('127.0.0.1', 50574)>
  self._invoke_excepthook(self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/selector_events.py:834: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=27>
  _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback

======================================================================
ERROR: test_shutdown_cleanly (test.test_asyncio.test_ssl.TestSSL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 155, in _silence_eof_received_warning
    yield
    ^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1228, in test_shutdown_cleanly
    run(client)
    ^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1222, in run
    self.loop.run_until_complete(
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/base_events.py", line 650, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1213, in _gather
    return await asyncio.gather(*tasks)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_asyncio/test_ssl.py", line 1191, in client
    reader, writer = await asyncio.open_connection(
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/streams.py", line 47, in open_connection
    transport, _ = await loop.create_connection(
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/base_events.py", line 1098, in create_connection
    transport, protocol = await self._create_connection_transport(
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/asyncio/base_events.py", line 1131, in _create_connection_transport
    await waiter
    ^^^^^^^^^^^^
ConnectionAbortedError: SSL handshake is taking longer than 10.0 seconds: aborting the connection

Stderr:
/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/threading.py:1033: ResourceWarning: unclosed <ssl.SSLSocket fd=9, family=2, type=1, proto=0, laddr=('127.0.0.1', 51261), raddr=('127.0.0.1', 50574)>
  self._invoke_excepthook(self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback

----------------------------------------------------------------------
Ran 1 test in 16.068s

FAILED (errors=1)
test test_asyncio failed
1 test failed again:
    test_asyncio

----------
components: Tests
messages: 415926
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_shutdown_cleanly() failed with timeout (10 seconds) on slow x86 Gentoo Non-Debug with X 3.x
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 24 05:29:54 2022
From: report at bugs.python.org (stephan)
Date: Thu, 24 Mar 2022 09:29:54 +0000
Subject: [New-bugs-announce] [issue47107] Navigation bar in python3103.chm
 is broken
Message-ID: <1648114194.88.0.410682635548.issue47107@roundup.psfhosted.org>


New submission from stephan <stephane.matamontero at eu.takata.com>:

As you see in 2022-03-24_python3.10.3.png
the navigation bar in python3103.chm is broken.

In 2022-03-24_python3.10.2.png you see the same 
the same for python3102.chm.

I suppose it would make sense:
- to hide this navigation bar when you create a chm
- to have a file download of the html docs as zip file for offline
  working (like in the djangoproject.com)

----------
assignee: docs at python
components: Documentation, Windows
files: 2022-03-24_python3.10.3.png
messages: 415930
nosy: docs at python, paul.moore, stephan, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Navigation bar in python3103.chm is broken
versions: Python 3.11
Added file: https://bugs.python.org/file50697/2022-03-24_python3.10.3.png

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

From report at bugs.python.org  Thu Mar 24 05:59:49 2022
From: report at bugs.python.org (Christian Bodt)
Date: Thu, 24 Mar 2022 09:59:49 +0000
Subject: [New-bugs-announce] [issue47108] asyncio-stream does not document
 exceptions
Message-ID: <1648115989.95.0.156752544907.issue47108@roundup.psfhosted.org>


New submission from Christian Bodt <christian.bodt at gmail.com>:

reader.read() might raise ConnectionResetError and possibly other exceptions, but this is not explained in the documentation.

See this stacktrace example:

Traceback (most recent call last):
  File "D:\Dropbox\repos\wxasync\src\examples\server.py", line 23, in handle_connection
    data = await reader.read(100)
  File "C:\Python-3.9\lib\asyncio\streams.py", line 684, in read
    await self._wait_for_data('read')
  File "C:\Python-3.9\lib\asyncio\streams.py", line 517, in _wait_for_data
    await self._waiter
  File "C:\Python-3.9\lib\asyncio\proactor_events.py", line 280, in _loop_reading
    data = fut.result()
  File "C:\Python-3.9\lib\asyncio\windows_events.py", line 812, in _poll
    value = callback(transferred, key, ov)
  File "C:\Python-3.9\lib\asyncio\windows_events.py", line 461, in finish_recv
    raise ConnectionResetError(*exc.args)
ConnectionResetError: [WinError 64] Le nom r?seau sp?cifi? n?est plus disponible

----------
assignee: docs at python
components: Documentation
messages: 415933
nosy: christian.bodt, docs at python
priority: normal
severity: normal
status: open
title: asyncio-stream does not document exceptions
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 24 06:44:34 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Thu, 24 Mar 2022 10:44:34 +0000
Subject: [New-bugs-announce] [issue47109] Old ctypes.macholib tests are
 ignored by python -m test
Message-ID: <1648118674.66.0.179855713714.issue47109@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

Some tests for `ctypes.macholib.dyld` and all tests for `ctypes.macholib.dylib` and `ctypes.macholib.framework` are located outside of expected `ctypes.test` module and were not ported from `assert` to `unittest` facilities. This causes the following problems:

- the tests aren't run by `python -m test` so they are effectively dead
- an end user can run them by `python -m ctypes.macholib.dyld`, `python -m ctypes.macholib.dylib`, and `python -m ctypes.macholib.framework`
- they are available even if a user chose to install CPython without tests

----------
components: Tests
messages: 415935
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Old ctypes.macholib tests are ignored by python -m test
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Mar 24 08:49:12 2022
From: report at bugs.python.org (Pieter Eendebak)
Date: Thu, 24 Mar 2022 12:49:12 +0000
Subject: [New-bugs-announce] [issue47110] Refactor bytearray strip methods
Message-ID: <1648126152.91.0.690193890673.issue47110@roundup.psfhosted.org>


New submission from Pieter Eendebak <pieter.eendebak at gmail.com>:

The bytearray strip, lstrip and rstrip methods contain a lot of duplicated code.

----------
components: Interpreter Core
messages: 415939
nosy: pieter.eendebak
priority: normal
severity: normal
status: open
title: Refactor bytearray strip methods
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 24 09:43:49 2022
From: report at bugs.python.org (Benyamin Guedj)
Date: Thu, 24 Mar 2022 13:43:49 +0000
Subject: [New-bugs-announce] [issue47111] ENUM TypeError using mixing
Message-ID: <1648129429.6.0.678446236905.issue47111@roundup.psfhosted.org>


New submission from Benyamin Guedj <benyamin621 at gmail.com>:

when trying to implement mixing with enum

```python
from typing import Tuple
from enum import Enum
class Blah(Tuple[str, ...], Enum):
    val = ('a', 'b')
```


>>> from typing import Tuple
>>> from enum import Enum
>>> class Blah(Tuple[str, ...], Enum):
...     val = ('a', 'b')
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\User\AppData\Local\Programs\Python\Python38\lib\enum.py", line 150, in __prepare__
    member_type, first_enum = metacls._get_mixins_(cls, bases)
  File "C:\Users\User\AppData\Local\Programs\Python\Python38\lib\enum.py", line 574, in _get_mixins_
    member_type = _find_data_type(bases) or object
  File "C:\Users\User\AppData\Local\Programs\Python\Python38\lib\enum.py", line 562, in _find_data_type
    raise TypeError('%r: too many data types: %r' % (class_name, data_types))
TypeError: 'Blah': too many data types: [<class 'tuple'>, <class 'typing.Generic'>]


note:
  the same code work on python 3.7, 3.9, 3.10



I have checked the source code of enum of 3.8

https://github.com/python/cpython/blob/3.8/Lib/enum.py

and it's not the same as the other version 

https://github.com/python/cpython/blob/3.9/Lib/enum.py

----------
components: Library (Lib)
messages: 415942
nosy: benyamin621
priority: normal
severity: normal
status: open
title: ENUM TypeError using mixing
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar 24 13:06:04 2022
From: report at bugs.python.org (Ramsey Thomson)
Date: Thu, 24 Mar 2022 17:06:04 +0000
Subject: [New-bugs-announce] [issue47112] RuntimeError: expected scalar type
 Long but found Int
Message-ID: <1648141564.18.0.17781153742.issue47112@roundup.psfhosted.org>


New submission from Ramsey Thomson <ramsey.thomson at gmail.com>:

Line 2846 of ~\anaconda3\lib\site-packages\torch\nn\functional.py in cross_entropy(input, target, weight, size_average, ignore_index, reduce, reduction, label_smoothing) results in > RuntimeError: expected scalar type Long but found Int
The above is called from line 1150 of ~\anaconda3\lib\site-packages\torch\nn\modules\loss.py in forward(self, input, target) which in turn is called from line 1102 of ~\anaconda3\lib\site-packages\torch\nn\modules\module.py in _call_impl(self, *input, **kwargs)

----------
components: Library (Lib)
messages: 415961
nosy: Ramsey
priority: normal
severity: normal
status: open
title: RuntimeError: expected scalar type Long but found Int
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Thu Mar 24 14:27:29 2022
From: report at bugs.python.org (Zombo)
Date: Thu, 24 Mar 2022 18:27:29 +0000
Subject: [New-bugs-announce] [issue47113] PermissionError on pip uninstall
Message-ID: <1648146449.62.0.573957246169.issue47113@roundup.psfhosted.org>


New submission from Zombo <srpen6 at gmail.com>:

I can install a package:

    pip install brotli

but if I try to remove, it fails:

    PS D:\Desktop> pip uninstall -y brotli
    Found existing installation: Brotli 1.0.9
    Uninstalling Brotli-1.0.9:
      Successfully uninstalled Brotli-1.0.9
    ERROR: Exception:
    Traceback (most recent call last):
      File "C:\python\lib\site-packages\pip\_internal\cli\base_command.py", line 167, in exc_logging_wrapper
        status = run_func(*args)
      File "C:\python\lib\site-packages\pip\_internal\commands\uninstall.py", line 102, in run
        uninstall_pathset.commit()
      File "C:\python\lib\site-packages\pip\_internal\req\req_uninstall.py", line 420, in commit
        self._moved_paths.commit()
      File "C:\python\lib\site-packages\pip\_internal\req\req_uninstall.py", line 273, in commit
        save_dir.cleanup()
      File "C:\python\lib\site-packages\pip\_internal\utils\temp_dir.py", line 173, in cleanup
        rmtree(self._path)
      File "C:\python\lib\site-packages\pip\_vendor\tenacity\__init__.py", line 326, in wrapped_f
        return self(f, *args, **kw)
      File "C:\python\lib\site-packages\pip\_vendor\tenacity\__init__.py", line 406, in __call__
        do = self.iter(retry_state=retry_state)
      File "C:\python\lib\site-packages\pip\_vendor\tenacity\__init__.py", line 362, in iter
        raise retry_exc.reraise()
      File "C:\python\lib\site-packages\pip\_vendor\tenacity\__init__.py", line 195, in reraise
        raise self.last_attempt.result()
      File "concurrent\futures\_base.py", line 439, in result
      File "concurrent\futures\_base.py", line 391, in __get_result
      File "C:\python\lib\site-packages\pip\_vendor\tenacity\__init__.py", line 409, in __call__
        result = fn(*args, **kwargs)
      File "C:\python\lib\site-packages\pip\_internal\utils\misc.py", line 124, in rmtree
        shutil.rmtree(dir, ignore_errors=ignore_errors, onerror=rmtree_errorhandler)
      File "shutil.py", line 747, in rmtree
      File "shutil.py", line 617, in _rmtree_unsafe
      File "shutil.py", line 615, in _rmtree_unsafe
    PermissionError: [WinError 5] Access is denied: 'C:\\Windows\\Temp\\pip-uninstall-fi5xmcvd\\_brotli.cp310-win_amd64.pyd'

whats strange is that after the failure, I can go back and manually remove the folder with no problem:

    PS D:\Desktop> python.exe
    Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import shutil
    >>> shutil.rmtree('C:\\Windows\\Temp\\pip-uninstall-fi5xmcvd')

----------
messages: 415965
nosy: 89z
priority: normal
severity: normal
status: open
title: PermissionError on pip uninstall
versions: Python 3.10

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

From report at bugs.python.org  Thu Mar 24 19:56:38 2022
From: report at bugs.python.org (Mark Bell)
Date: Thu, 24 Mar 2022 23:56:38 +0000
Subject: [New-bugs-announce] [issue47114] random.choice and random.choices
 have different distributions
Message-ID: <1648166198.78.0.653035976581.issue47114@roundup.psfhosted.org>


New submission from Mark Bell <mark00bell at googlemail.com>:

The docstring for `random.choices` indicates that
```
import random
random.choices(population, k=1)
```
should produce a list containing one item, where each item of `population` has equal likelihood of being selected. However `random.choices` draws elements for its sample by doing `population[floor(random() * len(population)]` and so relies on floating point numbers. Therefore not each item is equally likely to be chosen since floats are not uniformly dense in [0, 1] and this problem becomes worse as `population` becomes larger. 

Note that this issue does not apply to `random.choice(population)` since this uses `random.randint` to choose a random element of `population` and performs exact integer arithmetic. Compare https://github.com/python/cpython/blob/main/Lib/random.py#L371 and https://github.com/python/cpython/blob/main/Lib/random.py#L490

Could `random.choices` fall back to doing `return [choice(population) for _ in _repeat(None, k)]` if no weights are given? Similarly, is it also plausible to only rely on `random.randint` and integer arithmetic if all of the (cumulative) weights given to `random.choices` are integers?

----------
components: Library (Lib)
messages: 415981
nosy: Mark.Bell
priority: normal
severity: normal
status: open
title: random.choice and random.choices have different distributions
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 25 04:05:03 2022
From: report at bugs.python.org (Jeremiah Gabriel Pascual)
Date: Fri, 25 Mar 2022 08:05:03 +0000
Subject: [New-bugs-announce] [issue47115] Documentation inconsistency with
 the stable ABI
Message-ID: <1648195503.34.0.47585180018.issue47115@roundup.psfhosted.org>


New submission from Jeremiah Gabriel Pascual <nohackingofkrowten at gmail.com>:

In https://docs.python.org/3/c-api/typeobj.html#static-types, it says that PyTypeObject isn't part of the stable ABI. Yet, in https://docs.python.org/3/c-api/type.html#c.PyTypeObject, it says that PyTypeObject IS part of the stable ABI. Which is true?

----------
assignee: docs at python
components: Documentation
messages: 415989
nosy: Crowthebird, docs at python
priority: normal
severity: normal
status: open
title: Documentation inconsistency with the stable ABI

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

From report at bugs.python.org  Fri Mar 25 05:30:55 2022
From: report at bugs.python.org (Pieter Eendebak)
Date: Fri, 25 Mar 2022 09:30:55 +0000
Subject: [New-bugs-announce] [issue47116] Use _PyLong_FromUnsignedChar in
 bytearrayobject.c
Message-ID: <1648200655.15.0.54009409209.issue47116@roundup.psfhosted.org>


New submission from Pieter Eendebak <pieter.eendebak at gmail.com>:

In https://github.com/python/cpython/pull/31867 the method _PyLong_FromUnsignedChar was introduced for faster conversion of byteaarray elements.

We can use the method in more places

----------
components: Interpreter Core
messages: 415991
nosy: pieter.eendebak
priority: normal
severity: normal
status: open
title: Use _PyLong_FromUnsignedChar in bytearrayobject.c
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 25 06:06:05 2022
From: report at bugs.python.org (=?utf-8?q?Jon_=C3=85slund?=)
Date: Fri, 25 Mar 2022 10:06:05 +0000
Subject: [New-bugs-announce] [issue47117] repl segfaults on non utf-8 input
Message-ID: <1648202765.72.0.11778383238.issue47117@roundup.psfhosted.org>


New submission from Jon ?slund <jon at aslund.org>:

Some bytes that are non utf-8 segfaults python repl in 3.10 and later on linux. Example:

$ python3.10
Python 3.10.4 (main, Mar 24 2022, 14:20:44) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ?
Segmentation fault (core dumped)

It is treated correctly in Python 3.9 and earlier

$ python3.9
Python 3.9.12 (main, Mar 24 2022, 14:21:53) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ?
  File "<stdin>", line 0
    
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xb6 in position 0: invalid start byte

How to reproduce:

In Gnome on Ubuntu 20.04 with the Swedish keyboard layout, holding left alt and pressing the ? key enters the byte 0xb6 into the terminal.

I have only been able to make it crash the repl. I can't make it crash the parser. For instance trying to eval the byte.

----------
messages: 415992
nosy: jooon
priority: normal
severity: normal
status: open
title: repl segfaults on non utf-8 input
type: crash
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri Mar 25 10:20:59 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Mar 2022 14:20:59 +0000
Subject: [New-bugs-announce] [issue47118] test_run_keeps_context in
 test_asyncio fails
Message-ID: <1648218059.52.0.391905115882.issue47118@roundup.psfhosted.org>


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

$ ./python -m test -vuall test_asyncio
...
======================================================================
FAIL: test_run_keeps_context (test.test_asyncio.test_runners.RunnerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_asyncio/test_runners.py", line 299, in test_run_keeps_context
    self.assertEqual({cvar: 2}, dict(runner.run(get_context())))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: {<Con[47 chars]0>: 2} != {<Con[47 chars]0>: 2, <ContextVar name='decimal_context' at 0[164 chars]ow])}
- {<ContextVar name='cvar' default=-1 at 0x7f729c70e740>: 2}
?                                                          ^

+ {<ContextVar name='cvar' default=-1 at 0x7f729c70e740>: 2,
?                                                          ^

+  <ContextVar name='decimal_context' at 0x7f729d60e7b0>: Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999, Emax=999999, capitals=1, clamp=0, flags=[], traps=[InvalidOperation, DivisionByZero, Overflow])}

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


When run the test separately it passes successfully.

----------
components: Tests, asyncio
messages: 416000
nosy: asvetlov, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: test_run_keeps_context in test_asyncio fails
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 25 10:25:30 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Mar 2022 14:25:30 +0000
Subject: [New-bugs-announce] [issue47119] test_freeze_simple_script in
 test_tools fails
Message-ID: <1648218330.8.0.40703884352.issue47119@roundup.psfhosted.org>


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

$ ./python -X frozen_modules=off -m test -vuall test_tools -m test_freeze_simple_script
...
======================================================================
ERROR: test_freeze_simple_script (test.test_tools.test_freeze.TestFreeze)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/test/support/os_helper.py", line 396, in temp_dir
    yield path
    ^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/test/test_tools/test_freeze.py", line 27, in test_freeze_simple_script
    outdir, scriptfile, python = helper.prepare(script, outdir)
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Tools/freeze/test/freeze.py", line 134, in prepare
    copy_source_tree(srcdir, SRCDIR)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Tools/freeze/test/freeze.py", line 83, in copy_source_tree
    shutil.copytree(oldroot, newroot)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/shutil.py", line 558, in copytree
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/shutil.py", line 514, in _copytree
    raise Error(errors)
    ^^^^^^^^^^^^^^^^^^^
shutil.Error: [('/home/serhiy/py/cpython/tmp/y', '/tmp/tmp1swfh4ik/cpython/tmp/y', "[Errno 2] No such file or directory: '/home/serhiy/py/cpython/tmp/y'"), ('/home/serhiy/py/cpython/link', '/tmp/tmp1swfh4ik/cpython/link', "[Errno 2] No such file or directory: '/home/serhiy/py/cpython/link'"), ('/home/serhiy/py/cpython/Tools/unicode/python-mappings/CP932.TXT', '/tmp/tmp1swfh4ik/cpython/Tools/unicode/python-mappings/CP932.TXT', "[Errno 5] Input/output error: '/home/serhiy/py/cpython/Tools/unicode/python-mappings/CP932.TXT' -> '/tmp/tmp1swfh4ik/cpython/Tools/unicode/python-mappings/CP932.TXT'"), ('/home/serhiy/py/cpython/Tools/unicode/python-mappings-/CP949.TXT', '/tmp/tmp1swfh4ik/cpython/Tools/unicode/python-mappings-/CP949.TXT', "[Errno 5] Input/output error: '/home/serhiy/py/cpython/Tools/unicode/python-mappings-/CP949.TXT' -> '/tmp/tmp1swfh4ik/cpython/Tools/unicode/python-mappings-/CP949.TXT'"), ('/home/serhiy/py/cpython/Python/y', '/tmp/tmp1swfh4ik/cpython/Python/y', "[Errno 2] No such file or directory: '/home/serhiy/py/cpython/Python/y'"), ('/home/serhiy/py/cpython/dl', '/tmp/tmp1swfh4ik/cpython/dl', "[Errno 2] No such file or directory: '/home/serhiy/py/cpython/dl'"), ('/home/serhiy/py/cpython/issue36694/out.pickle', '/tmp/tmp1swfh4ik/cpython/issue36694/out.pickle', "[Errno 5] Input/output error: '/home/serhiy/py/cpython/issue36694/out.pickle' -> '/tmp/tmp1swfh4ik/cpython/issue36694/out.pickle'")]

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

----------
components: Demos and Tools, Tests
messages: 416001
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_freeze_simple_script in test_tools fails
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 25 10:30:53 2022
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 25 Mar 2022 14:30:53 +0000
Subject: [New-bugs-announce] [issue47120] Make all jumps relative
Message-ID: <1648218653.94.0.580682403112.issue47120@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

For some of our jump opcodes target is absolute, so it can easily require EXTENDED_ARGS. Our analysis [1] shows that turning all absolute jumps into relative jumps will eliminate almost all EXTENDED_ARGS on jumps. 

This will require a _BACK version for each jump type, which negates the oparg.

[1] https://github.com/faster-cpython/ideas/discussions/235#discussioncomment-2417022

----------
assignee: iritkatriel
components: Interpreter Core
messages: 416003
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Make all jumps relative
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Fri Mar 25 13:28:43 2022
From: report at bugs.python.org (Thomas Fischbacher)
Date: Fri, 25 Mar 2022 17:28:43 +0000
Subject: [New-bugs-announce] [issue47121] math.isfinite() can raise
 exception when called on a number
Message-ID: <1648229323.49.0.0271955914629.issue47121@roundup.psfhosted.org>


New submission from Thomas Fischbacher <tfish at google.com>:

>>> help(math.isfinite)
isfinite(x, /)
    Return True if x is neither an infinity nor a NaN, and False otherwise.

So, one would expect the following expression to return `True` or `False`. We instead observe:

>>> math.isfinite(10**1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: int too large to convert to float

(There likewise is a corresponding issue with other, similar, functions).

This especially hurts since PEP-484 states that having a Sequence[float] `xs` does not allow us to infer that `all(issubclass(type(x), float) for x in xs)` actually holds - since a PEP-484 "float" actually does also include "int" (and still, issubclass(int, float) == False).

Now, strictly speaking, `help(math)` states that

DESCRIPTION
    This module provides access to the mathematical functions
    defined by the C standard.

...but according to "man 3 isfinite", the math.h "isfinite" is a macro and not a function - and the man page does not show type information for that reason.

----------
messages: 416010
nosy: tfish2
priority: normal
severity: normal
status: open
title: math.isfinite() can raise exception when called on a number

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

From report at bugs.python.org  Fri Mar 25 14:24:12 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 25 Mar 2022 18:24:12 +0000
Subject: [New-bugs-announce] [issue47122] Fix the table of methods in the
 collections.abc documentation
Message-ID: <1648232652.41.0.171202431056.issue47122@roundup.psfhosted.org>


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

This pull request makes the following changes to the table of methods in the [`collections.abc` documentation](https://docs.python.org/3/library/collections.abc.html):

- `Reversible`: add `__iter__` abstract method;
- `Generator`: replace `__iter__` with inherited mixin `Iterator` methods;
- `MutableSequence`: add clear mixin method;
- `Set`: remove `__ne__` mixin method (not defined here but in `object`), add `__rand__` mixin method, add `__ror__` mixin method, add `__rsub__` mixin method, add `__rxor__` mixin method;
- `Mapping`: remove `__ne__` mixin method (not defined here but in `object`);
- `ItemsView`: add inherited mixin `MappingView` method and inherited mixin `Set` methods;
- `KeysView`: add inherited mixin `MappingView` method and inherited mixin `Set` methods;
- `ValuesView`: add inherited mixin `MappingView` method;
- `Coroutine`: add `__await__` abstract method;
- `AsyncGenerator`: replace `__aiter__` with inherited mixin `AsyncIterator` methods;
- footnotes: remove footnote 2 which is a duplicate of [the description of `collections.abc.Iterable`](https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterable).

----------
assignee: docs at python
components: Documentation
messages: 416013
nosy: docs at python, maggyero
priority: normal
pull_requests: 30195
severity: normal
status: open
title: Fix the table of methods in the collections.abc documentation
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri Mar 25 15:47:10 2022
From: report at bugs.python.org (ghost43)
Date: Fri, 25 Mar 2022 19:47:10 +0000
Subject: [New-bugs-announce] [issue47123] ZipFile.writestr should respect
 SOURCE_DATE_EPOCH
Message-ID: <1648237630.14.0.211482051392.issue47123@roundup.psfhosted.org>


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

Currently `ZipFile.writestr` writes the local time into the ZipFile.
(depends on both current time and local timezone)
See https://github.com/python/cpython/blob/20e6e5636a06fe5e1472062918d0a302d82a71c3/Lib/zipfile.py#L1816-L1817

This makes pip installing a package generate non-reproducible build artifacts.

Specifically, `Scripts/*.exe` files (created for packages that define entry_points/console_scripts) are not reproducible on Windows when installed by pip. This also leaks into the `*.dist-info/RECORD` files.

For example, after running `pip install wheel` or `pip install pyinstaller`,
in `wheel-0.37.1.dist-info/RECORD`, I have this line:
```
../../Scripts/wheel.exe,sha256=u9TbPw2XNs_F9uy7y2zwumuzAZDbOSB7BXjLHZ0tTHg,97103
```  
in `pyinstaller-4.10.dist-info/RECORD`, I have these lines:
```
../../Scripts/pyi-archive_viewer.exe,sha256=nC-9muPlIhUC1qvFkXHpyKJyRQqXISXxbUPXQ1XVOiM,97133
../../Scripts/pyi-bindepend.exe,sha256=udFHiAdndPpSwaIqmhmLEy36IUs1cNNoNQznSEnLJQQ,97128
../../Scripts/pyi-grab_version.exe,sha256=3ET9E841tFWujFL99aG4frzgwlP9f9pAkMgE0k2UGK0,97131
../../Scripts/pyi-makespec.exe,sha256=dJkfmITdLJhyPngmqziqqj5tH9qqfeQc5BTubeoXWUs,97127
../../Scripts/pyi-set_version.exe,sha256=sWmcOVS93fUY-wbdoz6ixBCvjy1tC4Aaw30DMmrmo-0,97130
../../Scripts/pyinstaller.exe,sha256=haInbhH0pImJn24cW4v917oUZmzXZj8OE89KFh4MO2Y,97112
```

Upon comparing multiple `Scripts/wheel.exe` files, I've found that the only difference is due to the above-mentioned timestamp embedded inside the exe (or rather, same timestamp embedded twice).

The `exe` files get created by `distlib` (vendored by pip).
Here is a traceback with an artificial exception to illustrate the codepath:
```
(env) PS C:\tmp> pip install --no-build-isolation pyinstaller
Collecting pyinstaller
  Using cached pyinstaller-4.10-py3-none-win_amd64.whl (2.0 MB)
Requirement already satisfied: setuptools in c:\tmp\env\lib\site-packages (from pyinstaller) (61.0.0)
Requirement already satisfied: pyinstaller-hooks-contrib>=2020.6 in c:\tmp\env\lib\site-packages (from pyinstaller) (2022.3)
Requirement already satisfied: altgraph in c:\tmp\env\lib\site-packages (from pyinstaller) (0.17.2)
Requirement already satisfied: pefile>=2017.8.1 in c:\tmp\env\lib\site-packages (from pyinstaller) (2021.9.3)
Requirement already satisfied: pywin32-ctypes>=0.2.0 in c:\tmp\env\lib\site-packages (from pyinstaller) (0.2.0)
Requirement already satisfied: future in c:\tmp\env\lib\site-packages (from pefile>=2017.8.1->pyinstaller) (0.18.2)
Installing collected packages: pyinstaller
ERROR: Exception:
Traceback (most recent call last):
  File "C:\tmp\env\lib\site-packages\pip\_internal\cli\base_command.py", line 167, in exc_logging_wrapper
    status = run_func(*args)
  File "C:\tmp\env\lib\site-packages\pip\_internal\cli\req_command.py", line 205, in wrapper
    return func(self, options, args)
  File "C:\tmp\env\lib\site-packages\pip\_internal\commands\install.py", line 405, in run
    installed = install_given_reqs(
  File "C:\tmp\env\lib\site-packages\pip\_internal\req\__init__.py", line 73, in install_given_reqs
    requirement.install(
  File "C:\tmp\env\lib\site-packages\pip\_internal\req\req_install.py", line 769, in install
    install_wheel(
  File "C:\tmp\env\lib\site-packages\pip\_internal\operations\install\wheel.py", line 729, in install_wheel
    _install_wheel(
  File "C:\tmp\env\lib\site-packages\pip\_internal\operations\install\wheel.py", line 646, in _install_wheel
    generated_console_scripts = maker.make_multiple(scripts_to_generate)
  File "C:\tmp\env\lib\site-packages\pip\_vendor\distlib\scripts.py", line 440, in make_multiple
    filenames.extend(self.make(specification, options))
  File "C:\tmp\env\lib\site-packages\pip\_internal\operations\install\wheel.py", line 427, in make
    return super().make(specification, options)
  File "C:\tmp\env\lib\site-packages\pip\_vendor\distlib\scripts.py", line 429, in make
    self._make_script(entry, filenames, options=options)
  File "C:\tmp\env\lib\site-packages\pip\_vendor\distlib\scripts.py", line 329, in _make_script
    self._write_script(scriptnames, shebang, script, filenames, ext)
  File "C:\tmp\env\lib\site-packages\pip\_vendor\distlib\scripts.py", line 263, in _write_script
    raise Exception(f"heyheyhey2. {sha256(launcher)=}. {sha256(shebang)=}. {sha256(zip_data)=}. " +
Exception: heyheyhey2. sha256(launcher)='a00a877acefc'. sha256(shebang)='58628e924f22'. sha256(zip_data)='a423496a0482'. ('SOURCE_DATE_EPOCH' in os.environ)=True
```
The interesting code is here:
https://github.com/pypa/distlib/blob/d0e3f49df5d1aeb9daeaaabf0391c9e13e4a6562/distlib/scripts.py#L251-L252
This calls into the cpython standard library, where `time.time()` gets written into the file:
https://github.com/python/cpython/blob/20e6e5636a06fe5e1472062918d0a302d82a71c3/Lib/zipfile.py#L1816-L1817

Ideally, either `distlib` or the stdlib  `zipfile` module should be changed to respect `SOURCE_DATE_EPOCH`, but it's not entirely clear to me which...

The attached patch changes `ZipFile.writestr` to respect `SOURCE_DATE_EPOCH` if set.


related https://github.com/pypa/distlib/issues/164
related https://github.com/spesmilo/electrum/issues/7739

----------
components: Library (Lib)
files: zipfile_respect_sourcedate.diff
keywords: patch
messages: 416015
nosy: ghost43
priority: normal
severity: normal
status: open
title: ZipFile.writestr should respect SOURCE_DATE_EPOCH
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50702/zipfile_respect_sourcedate.diff

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

From report at bugs.python.org  Fri Mar 25 20:48:30 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Mar 2022 00:48:30 +0000
Subject: [New-bugs-announce] [issue47124] explore hashlib use of the Apple
 CryptoKit macOS
Message-ID: <1648255710.38.0.570771334735.issue47124@roundup.psfhosted.org>


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

https://developer.apple.com/documentation/cryptokit/ in macOS 10.15+

This is a common place for platform specific hardware acceleration to be exposed to the user (especially on SoCs which often have non-standard hardware - Like Apples... which is presumably why they create this).

What they offer is limited, but when present and running on a recent enough macOS, using their and SHA2 and HMAC(SHA2) implementations as well as Insecure.SHA1 is probably better than OpenSSL's.  **Verify this.** It'd also allow those to be fast in a non-openssl build (as if anyone does those).

I know little about mac building and packaging and how to have something target an older OS and use a 10.15+ API. So if this winds up only being used from aarch64 macOS builds (10.15+ by definition IIRC?) that could also work.

I leave this issue for a macOS Apple API friendly person to take on.

This issue is cousin to the Linux one: https://bugs.python.org/issue47102

----------
components: Extension Modules, macOS
messages: 416032
nosy: gregory.p.smith, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: explore hashlib use of the Apple CryptoKit macOS
type: enhancement

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

From report at bugs.python.org  Fri Mar 25 20:53:13 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Mar 2022 00:53:13 +0000
Subject: [New-bugs-announce] [issue47125] Explore hashlib use of the Windows
 Crypto API NG
Message-ID: <1648255993.62.0.516641602637.issue47125@roundup.psfhosted.org>


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

https://docs.microsoft.com/en-us/windows/win32/seccng/creating-a-hash-with-cng

See if these are worthwhile vs using OpenSSL for the hashlib algorithms it supports.  OS APIs can in theory take better advantage of HW acceleration for performance.  Verify this on supported architectures.  Regardless it would allow some things to be fast if someone wanted to use a build without OpenSSL.

I'm not a Windows or Microsoft user.  I'm filing this for completeness, someone else would need to do the work.

similar macOS issue: https://bugs.python.org/issue47124
similar Linux issue: https://bugs.python.org/issue47102

----------
components: Extension Modules, Windows
messages: 416033
nosy: gregory.p.smith, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Explore hashlib use of the Windows Crypto API NG
type: performance

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

From report at bugs.python.org  Sat Mar 26 06:16:18 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Sat, 26 Mar 2022 10:16:18 +0000
Subject: [New-bugs-announce] [issue47126] Update to canonical PEP URLs
Message-ID: <1648289778.45.0.505813161282.issue47126@roundup.psfhosted.org>


New submission from Hugo van Kemenade <hugovk+python at gmail.com>:

With the recent implementation https://peps.python.org/pep-0676/ the canonical URL for PEPs has changed from, for example:

https://www.python.org/dev/peps/pep-0008/

to:

https://peps.python.org/pep-0008/

Redirects are in place so the old links still work, but let's update the docs and docstrings to use the new canonical form. There's also a couple of places in code, so a BPO number is needed.

----------
assignee: hugovk
components: Documentation, Library (Lib), Parser
messages: 416051
nosy: hugovk, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Update to canonical PEP URLs
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 26 08:16:33 2022
From: report at bugs.python.org (Kumar Aditya)
Date: Sat, 26 Mar 2022 12:16:33 +0000
Subject: [New-bugs-announce] [issue47127] Specialize call for c functions
 with METH_FASTCALL|METH_KEYWORDS
Message-ID: <1648296993.82.0.182445504362.issue47127@roundup.psfhosted.org>


New submission from Kumar Aditya <rahuladitya303 at gmail.com>:

Specialize call for c functions with METH_FASTCALL|METH_KEYWORDS flags.

It is the second largest PRECALL specialization failure as per the stats.

See https://github.com/faster-cpython/ideas/blob/main/stats.md#specialization-attempts-10

----------
components: Interpreter Core
messages: 416058
nosy: Dennis Sweeney, Mark.Shannon, kumaraditya303
priority: normal
pull_requests: 30204
severity: normal
status: open
title: Specialize call for c functions with METH_FASTCALL|METH_KEYWORDS
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 26 08:59:28 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Sat, 26 Mar 2022 12:59:28 +0000
Subject: [New-bugs-announce] [issue47128] Enhance Argument Clinic's NoneType
 return converter to give `void`
Message-ID: <1648299568.03.0.403379659681.issue47128@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

The attached PR makes the following possible (note that the impl has a `void` return type):

    /*[clinic input]
    _io._IOBase.writelines -> NoneType
        lines: object
        /
    [clinic start generated code]*/

    static void
    _io__IOBase_writelines_impl(PyObject *self, PyObject *lines)
    /*[clinic end generated code: output=f3feca36db72dbd1 input=286ba711cb7291ad]*/

Previously, the return type would be `Object *` with generated replacement of non-Py_None values to NULL on the other side.

So now there is no need to track whether NULL or Py_None should be returned. Or should it be Py_RETURN_NONE? Argument Clinic does it by itself returning NULL on errors and PyNone otherwise:

    static PyObject *
    _io__IOBase_writelines(PyObject *self, PyObject *lines)
    {
        PyObject *return_value = NULL;

        _io__IOBase_writelines_impl(self, lines);
        if (PyErr_Occurred()) {
            goto exit;
        }
        return_value = Py_None;
        Py_INCREF(Py_None);

    exit:
        return return_value;
    }

----------
components: Argument Clinic
messages: 416062
nosy: arhadthedev, larry
priority: normal
severity: normal
status: open
title: Enhance Argument Clinic's NoneType return converter to give `void`
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 26 11:08:27 2022
From: report at bugs.python.org (=?utf-8?q?Maciej_G=C3=B3rski?=)
Date: Sat, 26 Mar 2022 15:08:27 +0000
Subject: [New-bugs-announce] [issue47129] Improve errors messages in
 f-string syntax errors
Message-ID: <1648307307.69.0.710442348209.issue47129@roundup.psfhosted.org>


New submission from Maciej G?rski <macgors at gmail.com>:

When an empty expression is provided in curly brackets inside an f-string we get Syntax Error: "f-string: empty expression not allowed".


This is correct, however error with the same message is raised in the following cases: f"{!foo}", f"{!}", f"{:bar}", f"{=}", etc.
For example, should someone make an error and try to negate an expression with '!' instead of 'not' (i.e. f"{!True}"), they would get a confusing error, saying that the expression is empty, when it isn't. 

I propose we raise an error with the message: "f-string: optional specifier '%c' must follow a non-empty expression.

----------
components: Parser
messages: 416069
nosy: lys.nikolaou, macgors, pablogsal
priority: normal
severity: normal
status: open
title: Improve errors messages in f-string syntax errors

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

From report at bugs.python.org  Sat Mar 26 12:10:06 2022
From: report at bugs.python.org (malmiteria)
Date: Sat, 26 Mar 2022 16:10:06 +0000
Subject: [New-bugs-announce] [issue47130] mro and super don't feel so
 pythonic
Message-ID: <1648311006.19.0.353261149711.issue47130@roundup.psfhosted.org>


New submission from malmiteria <martin.milon at ensc.fr>:

Hi,

Before anything, i made a github repository about this topic here : https://github.com/malmiteria/super-alternative-to-super

The core of what i wanna discuss here is that i don't think mro and super (mainly because it relies on mro) are very pythonic. Mainly that some behaviors of the mro are too implicit, and are silencing what really should be errors.



Let me explain :
in case of multiple inheritence, resolving a child method from it's parent isn't an obvious task, and mro comes as a solution to that. However, i don't understand why we don't let the programmer solve it. I think this is similar to a merge conflict, and not letting the programmer resolve the conflict feels like silencing an error. This is especially infuriating when you realise that mro doesn't solve all possible scenarios, and then, simply refuses the opportunity to solve it to the programmer.
Then, super relying on mro gives off some weird behaviors, mainly, it's possible for a child definition to affect what a call to super means in it's parent. This feels like a side effect (which is the 'too implicit' thing i refer to).
I also don't understand why we can't simply pass the parent targeted as argument to super, instead of having no argument, or having to pass the current class and instances as argument :
super(child) is a proxy to parent, when super(parent) would make more sense to be the proxy to parent, in my mind.

I dive in more depths about those topics in the readme of the github repository i linked at the top of this comment.



what i propose is a solution that would follow those rules:

The mro alternative, which i called explicit method resolution aka EMR (which is probably not a good name since i apply it, as mro, to all class attributes), follow those rules :
 1) Straightforward case : the class definition has the method / attribute : this is the one EMR should resolve to
 2) Not found : the method / attribute can't be resolved in the class itself, or by any of it's parents, then it should raise an AttributeError
 3) Only on parent : the method / attribute can't be resolved in the class itself, and can only be resolved by one of it's parents, this is the one EMR should resolve to
 4) Multiple parent : the method / attribute can't be resolved in the class itself, and can be resolved by at least 2 of it's parents, then an ExplicitResolutionRequired error should be raised
 5) Transimittin errors : the method / attribute can't be resolved in the class itself, and one parent at least raises an ExplicitResolutionRequired error, then it should raise an ExplicitResolutionRequired error
 6) (optional?) Single source : when multiple parent can resolve a method from a single source (in case of diamond shape inheritence), the ExplicitResolutionRequired  is not needed

The super alternative, which i called __as_parent__ should follow those rules :
 1) reliability : the target __as_parent__ points to should not depend on anything other than the argument passed to it
 2) expliciteness : in case of multiple inheritence, the parent targetted should be passed as an argument to the __as_parent__ method.
 3) impliciteness : in case of simple inheritence, it is not needed to specify the parent targeted (since there can only be one, and it make it closer to the actual behavior of super in most cases)
 4) ancestors as targets : should be able to target ancestors, either direct or not (which is needed in case two grandparent define a method that a single parent share, there would be no other way to solve the ExplicitResolutionRequired otherwise)



this solution has a few advantages in my mind :
 - the current mro and super are more tightly coupled than the emr and __as_parent__ i propose here
 - the __as_parent__ is more reliable than super in its behavior, and should lead to an easier learning curve
 - the emr i propose as a replacement to mro allows for some inheritence tree mro doesn't allow.
 - the __as_parent__ method being able to target specific parent allows for different methods to visit the parents in different order easily, which today would be harder, since the parent visiting order is tightly coupled to the class definition
 - with emr, in case of problematic resolution, an error is raised to tell you about the problem, and ask you for explicit resolution, the current solution doesn't, which can lead to surprises closer to production environment.



A few possible downsides :
 - the transition would be a pain to deal with
 - the current mro allows for dependencies injection in the inheritence tree. I believe this feature should be untied from super and mro, but it would require some work.
 - the current super and mro are old enough to have been faced with issues and having been updated to solve those issues down the line. Any alternative would have to face those issues again and new ones down the line
 - any coexistence between those two solution would require some work to make sure they don't break one another (i've explored some of those scenarios in my repository, but i definitely didn't cover it all)


I believe that what i talk about here is definitely too much at once.
For exemple, adding a kwarg to super to specify the parent it targets would be a very easy change to add into python, and wouldn't require much more of what i talk about here, but it would still have some of the value i talk about here.
But overall, it all makes sense to me, and i wanted to share it all with you guys.

What do you think? does it makes sense? Am i missing something?

----------
messages: 416071
nosy: malmiteria
priority: normal
severity: normal
status: open
title: mro and super don't feel so pythonic
type: enhancement

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

From report at bugs.python.org  Sat Mar 26 15:15:49 2022
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 26 Mar 2022 19:15:49 +0000
Subject: [New-bugs-announce] [issue47131] Speedup test_unparse
Message-ID: <1648322149.94.0.511947690727.issue47131@roundup.psfhosted.org>


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

The string building and comparing of ast.dump() causes significant slowdowns on the large ASTs produced when doing the roundtrip test on the stdlib.

This PR avoids that cost by doing a direct node traversal and comparison.  It results in a 33% runtime improvement on machines to which I have access.

----------
components: Tests
messages: 416082
nosy: jkloth
priority: normal
severity: normal
status: open
title: Speedup test_unparse
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sat Mar 26 15:16:33 2022
From: report at bugs.python.org (Oleg Iarygin)
Date: Sat, 26 Mar 2022 19:16:33 +0000
Subject: [New-bugs-announce] [issue47132] Move tests from setobject.c to
 _testcapimodule
Message-ID: <1648322193.52.0.0635664464356.issue47132@roundup.psfhosted.org>


New submission from Oleg Iarygin <oleg at arhadthedev.net>:

Currently, tests for PySet/PyFrozenSet C API are defined in Objects/setobject.c and available via set.test_c_api().

Moving them to, for example, _testcapimodule gives the following advantanges:

- an internal, CPython-specific method stops being available in a public interface of the set class

- CPython already has tests grouped into dedicated packages

- the target package undefines NDEBUG thus making asserts available in release builds

- a user may choose to omit the tests from a build not carrying them around

- a file of 2.5k lines of codes becomes 152 lines smaller.

----------
components: C API, Tests
messages: 416083
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Move tests from setobject.c to _testcapimodule
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 26 16:56:32 2022
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 26 Mar 2022 20:56:32 +0000
Subject: [New-bugs-announce] [issue47133] enhance unittest to show test name
 and docstring on one line
Message-ID: <1648328192.86.0.657883961617.issue47133@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

When running unittest with the -v flag, if a test has errors, and has a docstring, the test name is shown on one line, and the docstring is shown on the next line -- and the ERROR word is shown with the docstring.

What this means is that:
- the test name is easily missed by anyone who isn't aware of that (I only recently found out when someone else pointed it out to me)
- grepping for ERROR doesn't reveal the test name, necessitating a search through the testing code to find the test that failed

There are two possible solutions, and the selection of which one should be discussed on python-dev:
- print the name and docstring, and ERROR, all on one line; or
- provide a command-line switch to select that behavior

---

For the experienced developers who see this:  please leave the issue for one of the new developers subscribed to core-mentorship.  Thank you.

----------
components: Tests
messages: 416090
nosy: ethan.furman
priority: low
severity: normal
stage: needs patch
status: open
title: enhance unittest to show test name and docstring on one line
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat Mar 26 18:10:10 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Mar 2022 22:10:10 +0000
Subject: [New-bugs-announce] [issue47134] Document the meaning of the number
 in OverflowError
Message-ID: <1648332610.23.0.998137740503.issue47134@roundup.psfhosted.org>


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

OverflowError sometimes (but not always) includes some sort of numeric code:

>>> 1e+300 ** 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: (34, 'Numerical result out of range')

but the meaning of the 34 is not documented:

https://docs.python.org/3/library/exceptions.html#OverflowError

help(OverflowError) is no more insightful, saying only:

    __init__(self, /, *args, **kwargs)
        Initialize self.  See help(type(self)) for accurate signature.

Other OverflowError exceptions do not include the numeric code:

>>> math.exp(10000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error

Is it an error code from C? Something to do with the number of digits of precision? An easter-egg to do with The Count Of Monte Cristo?

----------
assignee: docs at python
components: Documentation
messages: 416093
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Document the meaning of the number in OverflowError
type: enhancement
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/issue47134>
_______________________________________

From report at bugs.python.org  Sun Mar 27 06:16:04 2022
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 27 Mar 2022 10:16:04 +0000
Subject: [New-bugs-announce] [issue47135] Allow decimal.localcontext to
 accept keyword arguments to set context attributes
Message-ID: <1648376164.23.0.483054740742.issue47135@roundup.psfhosted.org>


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

Whenever I use decimal and need to change the context temporarily, without fail I try to write

with decimal.localcontext(prec=10):
    ...

or similar. Then I get surprised that it fails, and re-write it as

with decimal.localcontext() as ctx:
    ctx.prec = 10
    ...

Let's make the first version work. localcontext should accept keyword arguments corresponding to the same arguments accepted by Context, and set them on the context given.

A proof-of-concept wrapper function:

def localcontext(ctx=None, **kwargs):
    if ctx is None:
        ctx = decimal.getcontext().copy()
    for key, value in kwargs.items():
        setattr(ctx, key, value)
    return decimal.localcontext(ctx)

I think this would be a valuable, and useful, improvement to the decimal API.

----------
components: Library (Lib)
messages: 416114
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Allow decimal.localcontext to accept keyword arguments to set context attributes
versions: Python 3.11

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

From report at bugs.python.org  Sun Mar 27 07:17:56 2022
From: report at bugs.python.org (Takuo Matsuoka)
Date: Sun, 27 Mar 2022 11:17:56 +0000
Subject: [New-bugs-announce] [issue47136] Wrong value assigned automatically
 to the variable __module__ in the class body.
Message-ID: <1648379876.09.0.993153417089.issue47136@roundup.psfhosted.org>


New submission from Takuo Matsuoka <motogeomtop at gmail.com>:

In the creation of a class, it looks as if the value of the variable
__name__ gets assigned automatically to the variable __module__ in the
class body.  However, the correct name space where the value of
__name__ should be looked up is NOT the mapping object returned by the
method __prepare__
of the metaclass.  In the class body, the programmer may use the
variable __name__ for some other purposes, and might not notice
__module__ was messed up.  Here's a code which produces a problem.

```
class C(type):
    @classmethod
    def __prepare__(cls, /, *args, **kwargs):
        return dict(__name__ = "whatever")

class O(metaclass=C):
    print(__module__) # "whatever" printed
```

Consequently,

>>> O.__module__
'whatever'

The issue is different from but seems related to

https://bugs.python.org/issue28869

I haven't figured out the exact relation.

Thanks.

----------
components: Interpreter Core
messages: 416118
nosy: Takuo Matsuoka
priority: normal
severity: normal
status: open
title: Wrong value assigned automatically to the variable __module__ in the class body.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Mar 27 08:10:28 2022
From: report at bugs.python.org (qiu)
Date: Sun, 27 Mar 2022 12:10:28 +0000
Subject: [New-bugs-announce] [issue47137] MemoryError
Message-ID: <1648383028.98.0.518734676925.issue47137@roundup.psfhosted.org>


New submission from qiu <1425166100 at qq.com>:

Traceback (most recent call last):
  File "python_AFL.py", line 110, in runFuzzer
    runtime = runApplication(input_path, mode)
  File "python_AFL.py", line 75, in runApplication
    exec(f.read(), {'buff': input_data})    
  File "<string>", line 16, in <module>
  File "<string>", line 10, in fuzz
  File "/usr/lib/python3.6/codeop.py", line 122, in compile_command
    return _maybe_compile(_compile, source, filename, symbol)
  File "/usr/lib/python3.6/codeop.py", line 82, in _maybe_compile
    code = compiler(source, filename, symbol)
  File "/usr/lib/python3.6/codeop.py", line 102, in _compile
    return compile(source, filename, symbol, PyCF_DONT_IMPLY_DEDENT)
MemoryError

when I use codeop.compile_command( random input ), I get the error .
I wonder if I found the error with the Python codeop's library??
thanks!

----------
messages: 416120
nosy: Leilei
priority: normal
severity: normal
status: open
title: MemoryError
type: crash

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

From report at bugs.python.org  Mon Mar 28 04:17:25 2022
From: report at bugs.python.org (Hugo van Kemenade)
Date: Mon, 28 Mar 2022 08:17:25 +0000
Subject: [New-bugs-announce] [issue47138] Bump Sphinx to fix docs build
Message-ID: <1648455445.5.0.763190152581.issue47138@roundup.psfhosted.org>


New submission from Hugo van Kemenade <hugovk+python at gmail.com>:

The docs build on GitHub Actions is passing on `main` but has started failing for the `3.7` - `3.10` branches:

```
Missing the required blurb or sphinx-build tools.
Please run 'make venv' to install local copies.

make[1]: *** [Makefile:50: build] Error 1
```

https://github.com/python/cpython/actions/workflows/doc.yml
https://github.com/python/cpython/runs/5714593700?check_suite_focus=true

This is because the `PATH=./venv/bin:$PATH sphinx-build --version` check is failing:

```
/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/util/docutils.py:45: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
  __version_info__ = tuple(LooseVersion(docutils.__version__).version)
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Doc/./venv/bin/sphinx-build", line 5, in <module>
    from sphinx.cmd.build import main
  File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/cmd/build.py", line 25, in <module>
    from sphinx.application import Sphinx
  File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/application.py", line 42, in <module>
    from sphinx.registry import SphinxComponentRegistry
  File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/registry.py", line 24, in <module>
    from sphinx.builders import Builder
  File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/builders/__init__.py", line 26, in <module>
    from sphinx.util import import_object, logging, rst, progress_message, status_iterator
  File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/sphinx/util/rst.py", line 22, in <module>
    from jinja2 import environmentfilter
ImportError: cannot import name 'environmentfilter' from 'jinja2' (/home/runner/work/cpython/cpython/Doc/venv/lib/python3.10/site-packages/jinja2/__init__.py)
```

This is because `3.10` and `3.9` are still using old versions of Sphinx (3.2.1 and 2.4.4 respectively) which is incompatible with the newest Jinja2:

https://github.com/pallets/jinja/issues/1630

`main` is using a newer Sphinx (4.2.0), so it passes.

Bumping to Sphinx 4.5.0 will fix both `3.9` and `3.10`. `3.7` and `3.8` are affected too. We can bump `main` to use `4.5.0` as well.

----------
assignee: docs at python
components: Documentation
messages: 416149
nosy: docs at python, hugovk
priority: normal
severity: normal
status: open
title: Bump Sphinx to fix docs build
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/issue47138>
_______________________________________

From report at bugs.python.org  Mon Mar 28 05:48:02 2022
From: report at bugs.python.org (Richard Purdie)
Date: Mon, 28 Mar 2022 09:48:02 +0000
Subject: [New-bugs-announce] [issue47139] pthread_sigmask needs SIG_BLOCK
 behaviour explaination
Message-ID: <1648460882.85.0.215889211593.issue47139@roundup.psfhosted.org>


New submission from Richard Purdie <richard.purdie at linuxfoundation.org>:

I've been struggling to get signal.pthread_sigmask to do what I expected it to do from the documentation. Having looked at the core python code handling signals I now (think?!) I understand what is happening. It might be possible for python to improve the behaviour, or it might just be something to document, I'm not sure but I though I'd mention it.

I'd added pthread_sigmask(SIG_BLOCK, (SIGTERM,)) and pthread_sigmask(SIG_UNBLOCK, (SIGTERM,)) calls around a critical section I wanted to protect from the SIGTERM signal. I was still seeing SIGTERM inside that section. Using SIGMASK to restore the mask instead of SIG_UNBLOCK behaves the same.

What I hadn't realised is that firstly python defers signals to a convenient point and secondly that signals are processed in the main thread regardless of the thread they arrived in. This means that I can see SIGTERM arrive in my critical section as one of my other threads created in the background by the core python libs helpfully handles it.  This makes SIG_BLOCK rather ineffective in any threaded code.

To work around it, I can add my own handlers and have them track whether a signal arrived, then handle any signals after my critical section by re-raising them. It is possible python itself could defer processing signals masked with SIG_BLOCK until they're unblocked. Alternatively, a note in the documentation warning of the pitfalls here might be helpful to save someone else from wondering what is going on!

----------
components: Interpreter Core
messages: 416154
nosy: rpurdie
priority: normal
severity: normal
status: open
title: pthread_sigmask needs SIG_BLOCK behaviour explaination
versions: Python 3.10

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

From report at bugs.python.org  Mon Mar 28 06:46:47 2022
From: report at bugs.python.org (Ofek Shilon)
Date: Mon, 28 Mar 2022 10:46:47 +0000
Subject: [New-bugs-announce] [issue47140] configure --enable-optimizations
 with clang *12* fails to detect llvm-profdata
Message-ID: <1648464407.56.0.975002069724.issue47140@roundup.psfhosted.org>


New submission from Ofek Shilon <ofekshilon at gmail.com>:

Working on 3/228/2022 github trunk in Ubuntu20. If I use the shipped clang10 :
$ ./configure --enable-optimizations
succeeds. If however I -
$ export CC=clang-12
`configure` starts to fail with symptoms identical to https://bugs.python.org/issue36002:

checking for --enable-optimizations... yes
checking for --with-lto... no
checking for -llvm-profdata... no
configure: error: llvm-profdata is required for a --enable-optimizations build but could not be found.

Manually setting LLVM_PROFDATA is still a valid workaround.

----------
components: Build
messages: 416156
nosy: ofekshilon
priority: normal
severity: normal
status: open
title: configure --enable-optimizations with clang *12* fails to detect llvm-profdata
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 28 08:26:22 2022
From: report at bugs.python.org (=?utf-8?q?Vlastimil_Z=C3=ADma?=)
Date: Mon, 28 Mar 2022 12:26:22 +0000
Subject: [New-bugs-announce] [issue47141] EmailMessage may lack Mime-Version
Message-ID: <1648470382.24.0.396391704333.issue47141@roundup.psfhosted.org>


New submission from Vlastimil Z?ma <vlastimil at ziima.cz>:

When an `EmailMessage` is created without setting its content, it may lack the `MIME-Version` header. I encountered this behavior when creating a S/MIME signed message, but I believe it applies to any `EmailMessage` in general.

Example:


from email.message import EmailMessage

nested_message = EmailMessage()
nested_message.set_content("Gazpacho!")

env = EmailMessage()
env.add_header("Content-Type", "multipart/signed", protocol="application/pkcs7-signature", micalg='sha-256')
env.preamble = "This is an S/MIME signed message"
env.attach(nested_message)
print(str(env))


This results in a message with no `MIME-Version` header


Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg="sha-256"; boundary="===============4414940364499332856=="

This is an S/MIME signed message
--===============4414940364499332856==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Gazpacho!

--===============4414940364499332856==--


which violates section 4 of RFC 2045, see https://datatracker.ietf.org/doc/html/rfc2045#section-4


> Messages composed in accordance with this document MUST include such
   a header field, with the following verbatim text:

     MIME-Version: 1.0


and the section doesn't seem to be obsoleted by newer MIME related RFCs.

It's not clear why the `EmailMessage` shouldn't have the `MIME-Version` header defined in all cases, since it should represent the email message. I suggest to set the `MIME-version` header on `__init__` the same way `MIMEBase` does.

----------
components: email
messages: 416163
nosy: Vlastimil.Z?ma, barry, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage may lack Mime-Version
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Mar 28 08:48:15 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 28 Mar 2022 12:48:15 +0000
Subject: [New-bugs-announce] [issue47142] Document
 importlib.resources.abc.Traversable
Message-ID: <1648471695.21.0.705816081737.issue47142@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

importlib.resources.files is documented [0] as returning importlib.resources.abc.Traversable, which is an undocumented class (dead link) now. It should be documented.
The [source] has helpful docstrings, but is missing some details. I'd like to know these before writing some docs:

- Can the argument to `joinpath` contain path separators?
- Are the methods expected to raise specific exception types (e.g. if a resource is missing, or you call iterdir on a ?file?)? This seems quite important for people who implement the protocol.


[0]: https://docs.python.org/dev/library/importlib.resources.html#importlib.resources.files
[source]: https://github.com/python/cpython/blob/main/Lib/importlib/resources/abc.py#L49

----------
assignee: docs at python
components: Documentation
messages: 416164
nosy: docs at python, jaraco, petr.viktorin
priority: normal
severity: normal
status: open
title: Document importlib.resources.abc.Traversable

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

From report at bugs.python.org  Mon Mar 28 09:51:37 2022
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Mar 2022 13:51:37 +0000
Subject: [New-bugs-announce] [issue47143] Add functools.copy_class() which
 updates closures
Message-ID: <1648475497.69.0.517848943478.issue47143@roundup.psfhosted.org>


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

Class decorarators of attrs and stdlib dataclasses modules have to copy a class to *add* slots:

* old fixed attrs issue: https://github.com/python-attrs/attrs/issues/102
* attrs issue with Python 3.11: https://github.com/python-attrs/attrs/issues/907
* dataclasses issues with slots=True: https://bugs.python.org/issue46404


In the common case, copying a class is trivial:

    cls2 = type(cls)(cls.__name__, cls.__bases__, cls.__dict__)

Full dummy example just to change a class name without touching the original class (create a copy with a different name):
---
class MyClass:
    def hello(self):
        print("Hello", self.__class__)

def copy_class(cls, new_name):
    cls_dict = cls.__dict__.copy()
    # hack the dict to modify the class copy
    return type(cls)(new_name, cls.__bases__, cls_dict)

MyClass2 = copy_class(MyClass, "MyClass2")
MyClass2().hello()
---

Output:
---
Hello <class '__main__.MyClass2'>
---


The problem is when a class uses a closure ("__class__" here):
---
class MyClass:
    def who_am_i(self):
        cls = __class__
        print(cls)
        if cls is not self.__class__:
            raise Exception(f"closure lies: __class__={cls} {self.__class__=}")

def copy_class(cls, new_name):
    cls_dict = cls.__dict__.copy()
    # hack the dict to modify the class copy
    return type(cls)(new_name, cls.__bases__, cls_dict)

MyClass().who_am_i()
MyClass2 = copy_class(MyClass, "MyClass2")
MyClass2().who_am_i()
---

Output:
---
<class '__main__.MyClass'>
<class '__main__.MyClass'>
Traceback (most recent call last):
  ...
Exception: closure lies: __class__=<class '__main__.MyClass'> self.__class__=<class '__main__.MyClass2'>
---


The attrs project uses the following complicated code to workaround this issue (to "update closures"):
---

        # The following is a fix for
        # <https://github.com/python-attrs/attrs/issues/102>.  On Python 3,
        # if a method mentions `__class__` or uses the no-arg super(), the
        # compiler will bake a reference to the class in the method itself
        # as `method.__closure__`.  Since we replace the class with a
        # clone, we rewrite these references so it keeps working.
        for item in cls.__dict__.values():
            if isinstance(item, (classmethod, staticmethod)):
                # Class- and staticmethods hide their functions inside.
                # These might need to be rewritten as well.
                closure_cells = getattr(item.__func__, "__closure__", None)
            elif isinstance(item, property):
                # Workaround for property `super()` shortcut (PY3-only).
                # There is no universal way for other descriptors.
                closure_cells = getattr(item.fget, "__closure__", None)
            else:
                closure_cells = getattr(item, "__closure__", None)

            if not closure_cells:  # Catch None or the empty list.
                continue
            for cell in closure_cells:
                try:
                    match = cell.cell_contents is self._cls
                except ValueError:  # ValueError: Cell is empty
                    pass
                else:
                    if match:
                        set_closure_cell(cell, cls)
---
source: https://github.com/python-attrs/attrs/blob/5c040f30e3e4b3c9c0f27c8ac6ff13d604c1818c/src/attr/_make.py#L886

The implementation of the set_closure_cell() function is really complicate since cells were mutable before Python 3.10:
https://github.com/python-attrs/attrs/blob/5c040f30e3e4b3c9c0f27c8ac6ff13d604c1818c/src/attr/_compat.py#L203-L305


I propose to add a new functools.copy_class() function which copy a class and update the closures: end of the _create_slots_class() function:
---
cls = type(self._cls)(...)
for item in cls.__dict__.values():
    ... # update closures
return cls
---


The alternative is not to add a function to copy a class, just only to "update closures", but IMO such API would be more error prone.


I would like to implement this function, but first I would like to dicuss if it makes sense to add such function and check if it's the right abstraction.

----------
components: Library (Lib)
messages: 416168
nosy: eric.smith, petr.viktorin, rhettinger, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add functools.copy_class() which updates closures
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 28 10:32:05 2022
From: report at bugs.python.org (Douglas Raillard)
Date: Mon, 28 Mar 2022 14:32:05 +0000
Subject: [New-bugs-announce] [issue47144] Allow setting __classcell__
Message-ID: <1648477925.18.0.27195455918.issue47144@roundup.psfhosted.org>


New submission from Douglas Raillard <douglas.raillard at arm.com>:

The cell object __classcell__ currently cannot be set by code invoked by metaclass.__new__. Attempts to do so will be caught by builtin___build_class__ in bltimodule.c:

                } else {
                    const char *msg =
                        "__class__ set to %.200R defining %.200R as %.200R";
                    PyErr_Format(PyExc_TypeError, msg, cell_cls, name, cls);
                }

This is unfortunate as there is a use-case for such trickery: if the method of a class A are only used to be grafted onto another class B (monkey patching), A.__classcell__ should be set to B so that super() works as expected.

This can be useful in contexts where e.g. A.__new__ returns instances of B. B is not necessarily something under direct user control (it can be dynamically created by inheriting from a "template"), so A would be a better place for users to define custom method.

----------
components: Interpreter Core
messages: 416172
nosy: douglas-raillard-arm
priority: normal
severity: normal
status: open
title: Allow setting __classcell__
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 28 12:20:34 2022
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 28 Mar 2022 16:20:34 +0000
Subject: [New-bugs-announce] [issue47145] Improve graphlib.TopologicalSort
 by removing the prepare step
Message-ID: <1648484434.3.0.135225433651.issue47145@roundup.psfhosted.org>


New submission from Larry Hastings <larry at hastings.org>:

I've maintained my own topological sort class for a while now.  The API I came up with (or was it Tim and I?) was adopted for graphlib.TopologicalSort().  Some of my method names are slightly different, but the APIs are so similar, I can do a little renaming and run Lib/test/test_graphlib using my implementation.  (For clarity I'm going to write the rest of this issue using the names from graphlib.)

Recently I made an improvement to my version: it no longer has the modal behavior where there's a "before prepare" phase where you add nodes and an "after prepare" phase where you can call get_ready and done.

Instead, in my new and improved version the graph is always maintained in a "ready" state.  You can call add, get_ready, and done in any order, as much as you like.  prepare doesn't do anything besides the cycle check--but read on!

This approach required tweaking some semantics behind the scenes.  My graph object now maintains an internal "dirty" flag.  It's set to True after any edges are added, and only gets cleared after checking for cycles.  prepare runs this cycle check, but get_ready *also* runs this cycle check.  (Though in both cases, only when the dirty flag is set, of course.)  In theory this means you no longer need the prepare call.  However, it's still useful, because you can call it to check for a CycleError.

So, on the one hand, this means that get_ready can throw a CycleError, which it never did before.  On the other hand, it won't throw for existing users of the library, because they never add edges after their prepare call.  So this semantic change shouldn't break existing users, assuming they're not misusing the existing API.

Another wrinkle: adding a dependency on a node that's already been handed out by get_ready (but hasn't been returned by done) is ignored.  Again, not something existing users of graphlib can do, so this shouldn't break code.

There's one final semantic change I made worth knowing about: when you return a node via done, the graph simply forgets about it.  This means you could add it a second time (!) and it could go for a complete ride through the graph again, wheeee!  This also means that when all nodes have been returned by done, the graph is essentially returned to its initial pristine state.  This too seems completely harmless, because with the existing library it's illegal to add nodes to a graph after calling prepare, so nobody's doing it, so it won't break any code.

I'm happy to contribute my version.  But I was lazy and didn't worry about speed or memory implementation; it's strewn with sets and things.  I figured I could always optimize it later.  But "later" could become "now" if we were interested in trying to merge this behavior into Python's graphlib.

Interested?

----------
assignee: larry
components: Library (Lib)
messages: 416182
nosy: eric.smith, larry, pablogsal, tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve graphlib.TopologicalSort by removing the prepare step
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 28 12:50:08 2022
From: report at bugs.python.org (Eric Snow)
Date: Mon, 28 Mar 2022 16:50:08 +0000
Subject: [New-bugs-announce] [issue47146] PR check "Check if generated files
 are up to date" failing intermittently
Message-ID: <1648486208.6.0.128579800544.issue47146@roundup.psfhosted.org>


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

The "Check if generated files are up to date" GitHub check for PRs has been failing recently.  It may also impact local usage of "make regen-all".

Example: https://github.com/python/cpython/runs/5719012664

This may be related to gh-32061.

----------
assignee: eric.snow
components: Build
messages: 416193
nosy: Mark.Shannon, brandtbucher, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: PR check "Check if generated files are up to date" failing intermittently
versions: Python 3.11

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

From report at bugs.python.org  Mon Mar 28 13:48:12 2022
From: report at bugs.python.org (Patrick Reader)
Date: Mon, 28 Mar 2022 17:48:12 +0000
Subject: [New-bugs-announce] [issue47147] Allow `return yield from`
Message-ID: <1648489692.27.0.109128044871.issue47147@roundup.psfhosted.org>


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

I would like to be able to use a `yield from` expression in a `return` statement without parentheses, as a small quality of life tweak, i.e.:

    return yield from gen

instead of

    return (yield from gen)

I think this makes sense, since `yield from` can be used on the right-hand-side of an assignment, which accepts any expression, and so should `return`.

Here is a medium-sized real-world example of where I'm using this, where it would be nice to allow `return yield from`: https://gist.github.com/pxeger/48f97484364bf0b43dee974a8f0f4265

----------
components: Parser
messages: 416198
nosy: lys.nikolaou, pablogsal, pxeger
priority: normal
severity: normal
status: open
title: Allow `return yield from`
type: enhancement

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

From report at bugs.python.org  Tue Mar 29 02:33:29 2022
From: report at bugs.python.org (Rukchad Wongprayoon)
Date: Tue, 29 Mar 2022 06:33:29 +0000
Subject: [New-bugs-announce] [issue47148] sys.path.append before import the
 module causing module don't have doc-string?
Message-ID: <1648535609.4.0.0943377147502.issue47148@roundup.psfhosted.org>


New submission from Rukchad Wongprayoon <mooping3roblox at gmail.com>:

How to reproduce?

1. Make a random module with doc-string in the function
2. Make a python app in new folder (under the module folder) and import it by do 
```py
import sys
sys.path.append("..")
import <module>
```
3. then every function will don't have doc-string included in their function

----------
components: Library (Lib)
messages: 416242
nosy: timelessnesses
priority: normal
severity: normal
status: open
title: sys.path.append before import the module causing module don't have doc-string?
versions: Python 3.9

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

From report at bugs.python.org  Tue Mar 29 04:47:19 2022
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 29 Mar 2022 08:47:19 +0000
Subject: [New-bugs-announce] [issue47149] DatagramHandler doing DNS lookup
 on every log message
Message-ID: <1648543639.58.0.923135953431.issue47149@roundup.psfhosted.org>


New submission from Bruce Merry <bmerry at gmail.com>:

logging.DatagramHandler uses socket.sendto to send the messages. If the given address is a hostname rather than an IP address, it will do a DNS lookup every time.

I suspect that fixing issue 14855 will also fix this, since fixing that issue requires resolving the hostname to determine whether it is an IPv4 or IPv6 address to create a suitable socket.

I've run into this on 3.8, but tagging 3.10 since the code still looks the same.

----------
components: Library (Lib)
messages: 416247
nosy: bmerry
priority: normal
severity: normal
status: open
title: DatagramHandler doing DNS lookup on every log message
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar 29 05:26:11 2022
From: report at bugs.python.org (Jairo Llopis)
Date: Tue, 29 Mar 2022 09:26:11 +0000
Subject: [New-bugs-announce] [issue47150] HTTPRedirectHandler fails on POST
 for 307 and 308
Message-ID: <1648545971.96.0.690131735602.issue47150@roundup.psfhosted.org>


New submission from Jairo Llopis <yajo.sk8 at gmail.com>:

urllib.request.HTTPRedirectHandler fails if there is a 307 HTTP return code in a POST request.

In https://github.com/python/cpython/commit/c379bc5ec9012cf66424ef3d80612cf13ec51006 the same behaviour was implemented for 308.

According to https://datatracker.ietf.org/doc/html/rfc7538#section-3 IMHO this implementation is wrong for 308:

> Note: This status code is similar to 301 (Moved Permanently)
> ([RFC7231], Section 6.4.2), except that it does not allow changing
> the request method from POST to GET.

A similar note exists in https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.7 regarding code 307.

So, as long as the original redirection is in POST and it gets redirected to another POST, it should not be an error.

FWIW, in https://github.com/traefik/traefik/issues/7829#issuecomment-770210080 you can see that Traefik proxy uses 307 and 308 codes by default when redirecting non-GET requests.

Thus, urllib.request.HTTPRedirectHandler will fail to process any POST requests proxied by Traefik.

----------
components: Library (Lib)
messages: 416249
nosy: Jairo Llopis
priority: normal
severity: normal
status: open
title: HTTPRedirectHandler fails on POST for 307 and 308
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/issue47150>
_______________________________________

From report at bugs.python.org  Tue Mar 29 06:54:10 2022
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 29 Mar 2022 10:54:10 +0000
Subject: [New-bugs-announce] [issue47151] vfork() returns EINVAL if PID=1
Message-ID: <1648551250.97.0.0372959304176.issue47151@roundup.psfhosted.org>


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

The bug introduced here: #35823

If os.gepid() == 1, vfork() does not work and returns EINVAL.

Please add check for the current pid in condition where CPython chooses between fork() and vfork().

----------
components: Library (Lib)
messages: 416252
nosy: socketpair
priority: normal
severity: normal
status: open
title: vfork() returns EINVAL if PID=1
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Mar 29 11:54:32 2022
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Mar 2022 15:54:32 +0000
Subject: [New-bugs-announce] [issue47152] Reorganize the re module sources
Message-ID: <1648569272.18.0.653641722475.issue47152@roundup.psfhosted.org>


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

I proposed it several years ago on the Python-Dev mailing list and that change was approved in general. The reorganization was deferred because there were several known bugs in the RE engine (fixes for which could potentially be backported) and there were not merged patches waiting for review. Now the patch for atomic groups was merged and bugs was fixed (thanks to Ma Lin).

Both the C code and the Python code for the re module are distributed on few files, which lie down in directories Modules and Lib. It makes difficult to work with all related files because they are intermixed with source files of different modules.

The following changes are planned:

1. Convert the re module into a package. Make sre_* modules its submodules.
2. Move C sources for the _sre module into a separate directory.
3. Extract the code for generating definitions of C constants from definitions of Python constants into a separate script and add it in the Tools/scripts directory (there are precedences: generate_token.py, etc).

----------
components: Library (Lib), Regular Expressions
messages: 416268
nosy: ezio.melotti, gvanrossum, malin, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Reorganize the re module sources
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 29 13:32:48 2022
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Mar 2022 17:32:48 +0000
Subject: [New-bugs-announce] [issue47153] __doc__ should generally be
 writable
Message-ID: <1648575168.9.0.879509749563.issue47153@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

The __doc__ attribute of several object types is not writable: notably descriptors (method/member/getset), as well builtin methods.

This is annoying when wanting to generate docstrings for these objects dynamically. While it's not useful for regular Python code, it comes up when using Cython, which uses these types to implement the methods and properties of "cdef" classes.

----------
components: Interpreter Core
messages: 416277
nosy: pitrou
priority: normal
severity: normal
status: open
title: __doc__ should generally be writable
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 29 13:35:29 2022
From: report at bugs.python.org (Isuru Fernando)
Date: Tue, 29 Mar 2022 17:35:29 +0000
Subject: [New-bugs-announce] [issue47154] -arch <arch> detection in
 _osx_support generates false positives
Message-ID: <1648575329.21.0.561330062927.issue47154@roundup.psfhosted.org>


New submission from Isuru Fernando <isuruf at gmail.com>:

If `cflags` contains something like, `-I/Users/isuru/handy-archives-env/include`, then the code assumes that there is a `-arch` flag in it and errors with 

ValueError: Don't know machine value for archs=()

----------
components: Build
messages: 416278
nosy: isuruf
priority: normal
severity: normal
status: open
title: -arch <arch> detection in _osx_support generates false positives
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue Mar 29 16:26:04 2022
From: report at bugs.python.org (Furkan Onder)
Date: Tue, 29 Mar 2022 20:26:04 +0000
Subject: [New-bugs-announce] [issue47155] Strange behavior on the tuple that
 includes list
Message-ID: <1648585564.15.0.742761945333.issue47155@roundup.psfhosted.org>


New submission from Furkan Onder <furkanonder at protonmail.com>:

I am creating the tuple that includes a list and than I am trying to add new value to this list. Interpreter throw the error, but list is changing. I think it doesn't make sense. I think if we throw the type error, list shouldn't be change.

>>> tup = ('hi', 'test', ['a','b'])
>>> tup[2] += 'c'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> tup
('hi', 'test', ['a', 'b', 'c'])
>>>

----------
components: Interpreter Core
messages: 416291
nosy: furkanonder
priority: normal
severity: normal
status: open
title: Strange behavior on the tuple that includes list
versions: Python 3.10

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

From report at bugs.python.org  Tue Mar 29 18:10:53 2022
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Mar 2022 22:10:53 +0000
Subject: [New-bugs-announce] [issue47156] IDLE: make use of extended
 SyntaxError info.
Message-ID: <1648591853.36.0.0695463785531.issue47156@roundup.psfhosted.org>


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

In 3.10 and 3.11:

>>> while s := input.read(MAXBINSIZE):
...     while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):
  File "<stdin>", line 2
    while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)):
          ^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: cannot use assignment expressions with expression

IDLE only colors the 'l' of 'len'; add extended marking.

Some other errors gained extended location in 3.11 (only, I believe).  Adding colors may require monkeypatching method or subclassing class in traceback.py.  May have commented on issue or PR.

Related: Put SyntaxError in box.  (Anyone really want log of error?)

----------
assignee: terry.reedy
components: IDLE
messages: 416302
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: make use of extended SyntaxError info.
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue Mar 29 18:15:27 2022
From: report at bugs.python.org (Jonathan Balloch)
Date: Tue, 29 Mar 2022 22:15:27 +0000
Subject: [New-bugs-announce] [issue47157] bijective invertible map
Message-ID: <1648592127.3.0.298910668675.issue47157@roundup.psfhosted.org>


New submission from Jonathan Balloch <jon.balloch at gmail.com>:

It would be powerful to have a native implementation of a bijective map (e.g. a dictionary that hashed only one-to-one, but as a result either the "key" or the "value" could do lookup in O(1) time with the only overhead being the additional memory overhead of O(2N) as many references. 

Calling the object type "bimap", this could be easily implemented by simply having a call to bimap.inverse[value]=key, where the 'inverse' keyword is a reference table to the value-->key references. 

This is an important enhancement because currently the most efficient way to implement this is python is to, either: (1) make a custom object type that keeps two dictionaries, one that maps v->k and one that maps k->v, which takes twice as much memory, or (2) an object that has a custom "inverse" lookup call, which will be slower than O(1). In both cases there is no implicit enforcement of values being unique (necessary for a bijection). 

This should be added to the `collections` library as it will fit well along side other unique hashed collections such as "OrderedDict"

This will be beneficial to the community because transformations between semantic spaces (e.g. things that cannot be done in NumPy or similar) could be much more efficient and have cleaner, easier to read code if bijection maps were native and used one structure instead of two dictionaries.

----------
components: Interpreter Core
messages: 416304
nosy: jon.balloch
priority: normal
severity: normal
status: open
title: bijective invertible map
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue Mar 29 19:56:50 2022
From: report at bugs.python.org (Enji Cooper)
Date: Tue, 29 Mar 2022 23:56:50 +0000
Subject: [New-bugs-announce] [issue47158] logging.handlers.SysLogHandler
 doesn't get cleaned up properly on exit if it throws an exception
Message-ID: <1648598210.84.0.432046566119.issue47158@roundup.psfhosted.org>


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

Something I noticed when trying to repro another issue:

% python
Python 3.8.13 (default, Mar 16 2022, 17:28:59)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.handlers
>>> logging.handlers.SysLogHandler(address=("something-completely-bogus-doncha-know", 514))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/logging/handlers.py", line 829, in __init__
    ress = socket.getaddrinfo(host, port, 0, socktype)
  File "/usr/lib/python3.8/socket.py", line 918, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
>>>
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.8/logging/__init__.py", line 2127, in shutdown
    h.close()
  File "/usr/lib/python3.8/logging/handlers.py", line 892, in close
    self.socket.close()
AttributeError: 'SysLogHandler' object has no attribute 'socket'
% python3.9
Python 3.9.11 (main, Mar 16 2022, 17:27:06)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.handlers
>>> logging.handlers.SysLogHandler(address=("something-completely-bogus-doncha-know", 514))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/logging/handlers.py", line 873, in __init__
    ress = socket.getaddrinfo(host, port, 0, socktype)
  File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
>>>
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.9/logging/__init__.py", line 2142, in shutdown
    h.close()
  File "/usr/lib/python3.9/logging/handlers.py", line 936, in close
    self.socket.close()
AttributeError: 'SysLogHandler' object has no attribute 'socket'

This is happening because logging.Handler is calling logging._addHandlerRef in logging.Handler.__init__ and _removeHandlerRef at exit via logging.shutdown(..).

----------
components: Library (Lib)
messages: 416309
nosy: ngie
priority: normal
severity: normal
status: open
title: logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Mar 30 05:53:14 2022
From: report at bugs.python.org (Harsh Patel)
Date: Wed, 30 Mar 2022 09:53:14 +0000
Subject: [New-bugs-announce] [issue47159] multiprocessing.pool.Pool.apply
 block infinitely when stressed while using maxtasksperchild
Message-ID: <1648633994.35.0.529736180567.issue47159@roundup.psfhosted.org>


New submission from Harsh Patel <pharsh58 at gmail.com>:

We have a long-running process, which uses thread pool to get tasks and these threads then schedule the tasks and send them to multiprocessing.Pool (with maxtasksperchild limit set) using apply function. The original codebase is large but I have extracted this logic into a simple script for convenience so that you can see the issue. The issue is that after sometime the apply function call gets blocked infinitely. This only happens when we use maxtasksperchild and cause the library for multiple process recreation.

How script works:
Script creates an object of the Manager class which is responsible for creating a pool of threads and creating multiprocessing pool. Each thread is provided jobs to execute which is done by Scheduler.get_ready_jobs function call. I have designed this function in a way that 100 jobs are returned after every 5 calls to this function else it returns no jobs. Each thread while performing job sends processing_func to multiprocessing pool for execution which just prints "processing something" and exits.

Environment:
Python 3.7.10
Clang 12.0.5
MacOS v11.6 intel

Steps to reproduce:
1. Download the attached Python script and execute it
2. Let it run for 10-15 seconds and interrupt the execution

You will notice that some threads will exit successfully but for some, you will see the last message printed is "executing cpu_pool apply <thread_name>" which indicates these threads are blocked even though the actual processing_func is just calling a print function.

Warning: You will also not be able to exit the process without killing it.

As a note, this is my first Python issue report so please let me know if you need more information.

----------
components: Library (Lib)
files: example.py
messages: 416331
nosy: davin, harsh8398, pitrou
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool.apply block infinitely when stressed while using maxtasksperchild
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file50706/example.py

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

From report at bugs.python.org  Wed Mar 30 06:45:33 2022
From: report at bugs.python.org (ATUL VISHAL)
Date: Wed, 30 Mar 2022 10:45:33 +0000
Subject: [New-bugs-announce] [issue47160] round function is not working as
 expected
Message-ID: <1648637133.45.0.989235445931.issue47160@roundup.psfhosted.org>


New submission from ATUL VISHAL <vishalatul09 at gmail.com>:

round function is not working as expected .
my number is x= 0.967565*185000= 178999.525
round(x,2)
answer is coming as 178999.52
expected value is 178999.53

----------
components: Library (Lib)
files: compiled_result.jpg
messages: 416333
nosy: vishalatul09
priority: normal
severity: normal
status: open
title: round function is not working as expected
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file50707/compiled_result.jpg

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

From report at bugs.python.org  Wed Mar 30 07:01:52 2022
From: report at bugs.python.org (Jan Bronicki)
Date: Wed, 30 Mar 2022 11:01:52 +0000
Subject: [New-bugs-announce] [issue47161] pathlib method relative_to doesnt
 work with // in paths
Message-ID: <1648638112.11.0.570529320382.issue47161@roundup.psfhosted.org>


New submission from Jan Bronicki <janbronicki at gmail.com>:

The `//` path should be equivalent to `/`, and in some ways, it does behave like that in pathlib. But in the `relative_to` method on a `Path` object, it does not work
This is causing our CI pipeline to fail. In the documentation here you can see `//` being properly processed:

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


```python
In [10]: x=Path("/Library/Video") ; x.relative_to(Path("/"))
Out[10]: PosixPath('Library/Video')

In [11]: x=Path("//Library/Video") ; x.relative_to(Path("/"))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [11], in <cell line: 1>()
----> 1 x=Path("//Library/Video") ; x.relative_to(Path("/"))

File ~/.pyenv/versions/3.8.13/lib/python3.8/pathlib.py:908, in PurePath.relative_to(self, *other)
    906 if (root or drv) if n == 0 else cf(abs_parts[:n]) != cf(to_abs_parts):
    907     formatted = self._format_parsed_parts(to_drv, to_root, to_parts)
--> 908     raise ValueError("{!r} does not start with {!r}"
    909                      .format(str(self), str(formatted)))
    910 return self._from_parsed_parts('', root if n == 1 else '',
    911                                abs_parts[n:])

ValueError: '//Library/Video' does not start with '/'
```

----------
components: Library (Lib)
messages: 416336
nosy: John15321
priority: normal
severity: normal
status: open
title: pathlib method relative_to doesnt work with // in paths
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar 30 07:11:40 2022
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 30 Mar 2022 11:11:40 +0000
Subject: [New-bugs-announce] [issue47162] Add call trampoline to work around
 bad fpcasts on Emscripten
Message-ID: <1648638700.22.0.607965445304.issue47162@roundup.psfhosted.org>


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

WASM cannot handle function calls with bad function pointer casts yet. Hood Chatham explained the issue in Pyodide patch https://github.com/pyodide/pyodide/blob/0.19.1/cpython/patches/0001-call-trampolines-to-handle-fpcast-troubles.patch

---
The wasm call_indirect instruction takes a function signature as an immediate
argument (an immediate argument is one which is determined statically at compile
time). The web assembly runtime checks at runtime that the function pointer we
are attempting to call has a signature which matches the asserted function
signature, if they don't match, the runtime traps with "indirect call signature
mismatch". The codegen provided by default by the emscripten toolchain produces
an ABI that also has this constraint.

By contrast, typical native ABIs handle function pointer casts very gracefully:
extra arguments are ignored, missing arguments are filled in as 0, even wrong
return values are completely fine.

The Python ecosystem is full of code which contain function pointer casts.
Emscripten offers a second "EMULATE_FPCASTS" ABI that fixes many of these
issues, but it shims in the function pointer cast support in a binaryen pass
that happens on the fully linked wasm module. At this point, lots of information
has been destroyed and as a result the only possible solutions are extremely
costly in run time, stack space, and code size.

We wish to avoid these costs. Patching the packages is prohibitively time
consuming and boring, especially given our limited developer effort. I have
explored making automated detection tools, and these work. However, getting
these tools included into the CI of Python ecosystem packages would be
prohibitively time consuming.

There is a best of both worlds solution. It is possible to define an ABI which
allows for specific types of function pointer casts with neglible costs. I hope
to do this in future work. However, this will require custom llvm passes.
Because llvm is implemented in C++ which has very poor ABI compatibility, this
means our whole toolchain needs to be built against the same version of llvm,
from llvm all the way down to binaryen and the wasm binary toolkit.

In the meantime, most bad function pointer calls happen in a small number of
locations. Calling a function pointer from Javascript has no restrictions on
arguments. Extra arguments can be provided, arguments can be left off, etc with
no issue (this mimics Javascript's typical function call semantics). So at the
locations where the bad calls occur, we patch in a trampoline which calls out to
Javascript to make the call for us. Like magic, the problem is gone. Research
shows that the performance cost of this is surprisingly low too.
---

Bad function pointer casts lead to fatal runtime errors like this:

worker.js onmessage() captured an uncaught exception: RuntimeError: function signature mismatch
RuntimeError: function signature mismatch
    at create_builtin (<anonymous>:wasm-function[3512]:0x14f6df)
    at _imp_create_builtin (<anonymous>:wasm-function[3520]:0x14fe1d)
    at cfunction_vectorcall_O (<anonymous>:wasm-function[1871]:0x91e84)
    at _PyVectorcall_Call (<anonymous>:wasm-function[839]:0x4e220)
    at _PyObject_Call (<anonymous>:wasm-function[842]:0x4e4f5)
    at PyObject_Call (<anonymous>:wasm-function[843]:0x4e595)
    at _PyEval_EvalFrameDefault (<anonymous>:wasm-function[3114]:0x120541)
    at _PyEval_Vector (<anonymous>:wasm-function[3115]:0x1229ab)
    at _PyFunction_Vectorcall (<anonymous>:wasm-function[845]:0x4e6ca)
    at object_vacall (<anonymous>:wasm-function[859]:0x4f3d0)
worker sent an error! undefined:undefined: function signature mismatch


I propose to include the downstream patch from Pyodide but make the call trampoline feature opt-in. An opt-in allows Pyodide to use the trampolines in production while we can test core and 3rd party modules without the trampoline easily.

----------
components: Interpreter Core
messages: 416339
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add call trampoline to work around bad fpcasts on Emscripten
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 07:49:35 2022
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 30 Mar 2022 11:49:35 +0000
Subject: [New-bugs-announce] [issue47163] "unterminated subpattern" in valid
 regex if re.VERBOSE is used
Message-ID: <1648640975.38.0.120656824245.issue47163@roundup.psfhosted.org>


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

In this code, the same regex is compiled with and without re.VERBOSE.  Without, it compiles fine.  With, it fails with an "unterminated subpattern" error.

    list_num_rx1 =     r"""(?P<paren>\()?(\d+|#|[a-z])(?(paren)\)|\.)"""
    list_num_rx2 = r"""(?x)(?P<paren>\()?(\d+|#|[a-z])(?(paren)\)|\.)"""
    
    # This works:
    re.compile(list_num_rx1)
    # Either of these fails:
    re.compile(list_num_rx1, flags=re.VERBOSE)
    re.compile(list_num_rx2)

(What I really wanted was this, but the error happens without the multiline string:)

    list_num_rx = r"""(?x)
        (?P<paren>\()?          # maybe an opening paren
        (\d+|#|[a-z])           # the number: 123, or #, or a-z
        (?(paren)               # if we had an opening paren..
            \)|                 #   then we need a closing paren
            \.                  #   otherwise a dot.
        )
        """

----------
components: Regular Expressions
messages: 416340
nosy: ezio.melotti, mrabarnett, nedbat
priority: normal
severity: normal
status: open
title: "unterminated subpattern" in valid regex if re.VERBOSE is used

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

From report at bugs.python.org  Wed Mar 30 08:28:10 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Mar 2022 12:28:10 +0000
Subject: [New-bugs-announce] [issue47164] [C API] Add private "CAST" macros
 to clean up casts in C code
Message-ID: <1648643290.07.0.954478247887.issue47164@roundup.psfhosted.org>


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

Last years, I started to add "CAST" macros like:

#define _PyObject_CAST(op) ((PyObject*)(op))
#define _PyType_CAST(op) (assert(PyType_Check(op)), (PyTypeObject*)(op))

Example of usage:

#define PyObject_TypeCheck(ob, type) PyObject_TypeCheck(_PyObject_CAST(ob), type)

These macros avoids parenthesis. Example without CAST macro:

#define PyCFunction_GET_FLAGS(func) \
        (((PyCFunctionObject *)func) -> m_ml -> ml_flags)

Currently, inline cast requires adding parenthesis:

   ((PyCFunctionObject *)func)

IMO it's more readable with a CAST macro:

#define _PyCFunction_CAST(func) ((PyCFunctionObject *)func)
#define PyCFunction_GET_FLAGS(func) \
        (_PyCFunction_CAST(func)->m_ml->ml_flags)


I propose to add more CAST macros.

By the way, the current Python C API is not fully compatible with C++. "(type)expr" C syntax is seen as "old-style cast" in C++ which recommends static_cast<type>(expr), reinterpret_cast<type>(expr), or another kind of cast. But I prefer to discuss C++ in a separated issue ;-) IMO without considering C++, adding CAST macros is worth it for readability.

I am preparing pull requests for add CAST macros and use existing CAST macros.

----------
components: C API
messages: 416350
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Add private "CAST" macros to clean up casts in C code
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 10:14:35 2022
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Mar 2022 14:14:35 +0000
Subject: [New-bugs-announce] [issue47165] [C API] Test that the Python C API
 is compatible with C++
Message-ID: <1648649675.83.0.616089924769.issue47165@roundup.psfhosted.org>


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

There are more and more popular projects using the Python C API. The first big player is pybind11:
"Seamless operability between C++11 and Python"
https://pybind11.readthedocs.io/

Recently, I proposed a PR to add Python 3.11 support to the datatable project:
https://github.com/h2oai/datatable/pull/3231

My PR uses pythoncapi_compat.h header file which provides recent C API functions to old Python functions. The header file implements these functions as static inline function.

Problem: a static inline function implemented in a C header file used in a C++ code file can emit C++ compiler warnings.

In datatable, I got two kinds of C++ compiler warnings:

* Usage of the C NULL constant: C++ prefers nullptr
* "Old-style" cast like (PyObject*)obj: C++ prefers static_cast, reinterpret_cast, etc.

It seems like these compiler warnings are not enabled by default. The datatable project seems enabling them in its CI and I was asked to fix these warnings.

In the pythoncapi-compat project (*), I chose to use nullptr and reinterpret_cast if the "__cplusplus" macro is defined. Example:

---
// C++ compatibility
#ifdef __cplusplus
#  define PYCAPI_COMPAT_CAST(TYPE, EXPR) reinterpret_cast<TYPE>(EXPR)
#  define PYCAPI_COMPAT_NULL nullptr
#else
#  define PYCAPI_COMPAT_CAST(TYPE, EXPR) ((TYPE)(EXPR))
#  define PYCAPI_COMPAT_NULL NULL
#endif

// Cast argument to PyObject* type.
#ifndef _PyObject_CAST
#  define _PyObject_CAST(op) PYCAPI_COMPAT_CAST(PyObject*, op)
#endif
---

(*) https://github.com/python/pythoncapi_compat


It's unclear to me if the Python C API has or has not the same issue than pythoncapi_compat.h.


Last years, some old macros of the Python C API have been converted to static inline functions, like Py_INCREF(). It's unclear to me if these compiler warnings happen on Py_INCREF(). I don't understand why, but static inline macros from Python.h didn't emit compiler warnings in datatable, whereas similar static inline functions of pythoncapi_compat.h emitted compiler warnings.

Maybe there is a difference between <Python.h> and "Python.h". Or maybe it depends if the header file is a "local" file, or a "system" header file (ex: installed in /usr/include/ on Linux).


A first step would be to build a C++ extension as part of the Python test suite and check that there is no compiler warning. My GH-32175 PR is a proof-of-concept of that.

I don't know which C++ version we should target. pybind11 targets C++11. See bpo-39355 for a discussion about C++20: usage of the C++20 "module" keyword... which is a "contextual keyword" in practice.

----------
components: C API
messages: 416359
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Test that the Python C API is compatible with C++
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 10:49:32 2022
From: report at bugs.python.org (Thomas MK)
Date: Wed, 30 Mar 2022 14:49:32 +0000
Subject: [New-bugs-announce] [issue47166] Dataclass transform should ignore
 TypeAlias variables
Message-ID: <1648651772.62.0.141726987387.issue47166@roundup.psfhosted.org>


New submission from Thomas MK <tmke at posteo.net>:

The dataclass transformation ignores attributes that are annotated as ClassVar. I think it should also ignore attributes that are annotated as TypeAlias.

Specifically, I have this usecase in mind:


class RunMode(Enum):
    release = auto()
    debug = auto()

@dataclass
class Run:
    Mode: TypeAlias = RunMode
    mode: Mode = Mode.release

----------
components: Library (Lib)
messages: 416368
nosy: thomkeh
priority: normal
severity: normal
status: open
title: Dataclass transform should ignore TypeAlias variables
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Mar 30 11:34:50 2022
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 30 Mar 2022 15:34:50 +0000
Subject: [New-bugs-announce] [issue47167] Allow overriding future-task
 compliance check in asyncio
Message-ID: <1648654490.03.0.819318508338.issue47167@roundup.psfhosted.org>


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

Now asyncio.Task has a strict hardcoded check for futures processes on task's step.
Sometimes third-party library [1] wants to replace it with custom logic.
Currently it is impossible without implementing the full asyncio.Task replacement from scratch.
`asyncio.Task` is a non-trivial highly optimized part of async, keeping a third-party version in sync with the reference implementation takes more time and effort than it should be.

This issue proposes adding `Task._check_future(future)` method that could be overridden in subclasses.  The default C implementation uses a fast path that has no performance penalty.

1. https://github.com/aio-libs/aioloop-proxy implements nested loop proxies that are very useful for writing tests. A proxy can work in parallel with ancestors but checks all own acquired resources cleanup on 
the proxy closing.

----------
components: asyncio
messages: 416374
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Allow overriding future-task compliance check in  asyncio
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 11:39:32 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 30 Mar 2022 15:39:32 +0000
Subject: [New-bugs-announce] [issue47168] Improvements for stable ABI
 definition files
Message-ID: <1648654772.36.0.475029979354.issue47168@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

This issue groups together a few changes I'd like to make:

- Rename Doc/data/stable_abi.dat to *.csv, so it gets syntax highlighting. (The only user of that file should be the Sphinx extension)
- Mark autogenerated files as such in .gitattributes
- Convert Misc/stable_abi.txt to TOML, and change the parser to match (this will need a heads-up on python-dev)

----------
messages: 416376
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Improvements for stable ABI definition files

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

From report at bugs.python.org  Wed Mar 30 11:52:37 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 30 Mar 2022 15:52:37 +0000
Subject: [New-bugs-announce] [issue47169] Stable ABI: Some optional
 (#ifdef'd) functions aren't handled correctly
Message-ID: <1648655557.05.0.882264493098.issue47169@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

- PyThread_get_thread_native_id is only available when PY_HAVE_THREAD_NATIVE_ID is defined. The test currently always expects it to be available.
- PyOS_CheckStack is only available when USE_STACKCHECK is defined (i.e. on Windows). It should be exported from the DLL.

I plan to:
- add the appropriate metadata
- improve handling & testing of such optional functions in general

----------
components: C API
messages: 416377
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Stable ABI: Some optional (#ifdef'd) functions aren't handled correctly

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

From report at bugs.python.org  Wed Mar 30 12:28:35 2022
From: report at bugs.python.org (Christian Ascia)
Date: Wed, 30 Mar 2022 16:28:35 +0000
Subject: [New-bugs-announce] [issue47170] py launcher on windows opens new
 terminal window when parsing python script with shebang
Message-ID: <1648657715.1.0.645220705406.issue47170@roundup.psfhosted.org>


New submission from Christian Ascia <asciachristian at gmail.com>:

Hi, as the title describes, i noticed this unfornutate behavior preventing me to run directly python scripts in terminal without using the py command. I searched in the documentation but i couldn't find flags to prevent py launcher from opening a new window.

----------
components: Windows
messages: 416380
nosy: asciachristian, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: py launcher on windows opens new terminal window when parsing python script with shebang
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed Mar 30 13:08:02 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Mar 2022 17:08:02 +0000
Subject: [New-bugs-announce] [issue47171] Enable py.exe install in Windows
 ARM64 installer
Message-ID: <1648660082.91.0.301470009561.issue47171@roundup.psfhosted.org>


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

Currently the launcher is not installed by the installer. We need to reenable it.

----------
assignee: steve.dower
components: Windows
messages: 416385
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Enable py.exe install in Windows ARM64 installer
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 13:28:54 2022
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 30 Mar 2022 17:28:54 +0000
Subject: [New-bugs-announce] [issue47172] Make virtual opcodes in the
 compiler > 256 and is_jump() identify only proper jumps
Message-ID: <1648661334.4.0.0596431149271.issue47172@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at gmail.com>:

There are a few "virtual opcodes" which are internal to the compiler. They can have values > 256. This way we don't waste any valid opcodes on them, and it is easier to detect when one of them escapes the compiler into the assemble stage.

In addition, there is an is_jump() function that treats the exception handling opcodes as jumps (and also assumes that any opcode >= SETUP_WITH is a jump):

static inline int
 is_jump(struct instr *i)
 {
    return i->i_opcode >= SETUP_WITH || is_bit_set_in_table(_PyOpcode_Jump, i->i_opcode);
 }

Then there is is_block_push just for the three virtual exception block opcodes:

static inline int
is_block_push(struct instr *instr)
{
    int opcode = instr->i_opcode;
    return opcode == SETUP_FINALLY || opcode == SETUP_WITH || opcode == SETUP_CLEANUP;
}

We can make is_jump return true just for jumps, and call is_block_push as well when it is needed (currently sometimes we call is_jump when there cannot be virtual opcodes anymore so we can assert that instead, and in one place we call is_jump and then exclude the virtual opcodes. Both of these will become clearer after we make this change).

----------
assignee: iritkatriel
components: Interpreter Core
messages: 416386
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Make virtual opcodes in the compiler > 256 and is_jump() identify only proper jumps
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 13:38:03 2022
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Mar 2022 17:38:03 +0000
Subject: [New-bugs-announce] [issue47173] test_launcher fails on win-arm64
 buildbot
Message-ID: <1648661883.7.0.386202560122.issue47173@roundup.psfhosted.org>


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

Test failures: https://buildbot.python.org/all/#/builders/730/builds/4307

======================================================================
FAIL: test_filter_to_company (test.test_launcher.TestLauncher)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Workspace\buildarea\3.x.linaro-win-arm64.nondebug\build\Lib\test\test_launcher.py", line 311, in test_filter_to_company
    self.assertEqual("X.Y.exe", data["LaunchCommand"])
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'X.Y.exe' != 'C:\\Workspace\\buildarea\\venv_310\\Scripts\\python.exe'
- X.Y.exe
+ C:\Workspace\buildarea\venv_310\Scripts\python.exe
======================================================================
FAIL: test_py_default (test.test_launcher.TestLauncher)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Workspace\buildarea\3.x.linaro-win-arm64.nondebug\build\Lib\test\test_launcher.py", line 370, in test_py_default
    self.assertEqual("PythonTestSuite", data["SearchInfo.company"])
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'PythonTestSuite' != '(null)'
- PythonTestSuite
+ (null)
======================================================================
FAIL: test_py_shebang (test.test_launcher.TestLauncher)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Workspace\buildarea\3.x.linaro-win-arm64.nondebug\build\Lib\test\test_launcher.py", line 392, in test_py_shebang
    self.assertEqual("PythonTestSuite", data["SearchInfo.company"])
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'PythonTestSuite' != '(null)'
- PythonTestSuite
+ (null)

----------
components: Windows
messages: 416389
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_launcher fails on win-arm64 buildbot
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 15:00:12 2022
From: report at bugs.python.org (Erik De Bonte)
Date: Wed, 30 Mar 2022 19:00:12 +0000
Subject: [New-bugs-announce] [issue47174] Define behavior of
 descriptor-typed fields on dataclasses
Message-ID: <1648666812.33.0.43566752411.issue47174@roundup.psfhosted.org>


New submission from Erik De Bonte <erikd at microsoft.com>:

Recent discussions about PEP 681 (dataclass_transform) have focused on support for descriptor-typed fields. See the email thread here: https://mail.python.org/archives/list/typing-sig at python.org/thread/BW6CB6URC4BCN54QSG2STINU2M7V4TQQ/

Initially we were thinking that dataclass_transform needed a new parameter to switch between two modes. In one mode, it would use the default behavior of dataclass. In the other mode, it would be smarter about how descriptor-typed fields are handled. For example, __init__ would pass the value for a descriptor-typed field to the descriptor's __set__ method. However, Carl Meyer found that dataclass already has the desired behavior at runtime! We missed this because mypy and Pyright do not correctly mirror this runtime behavior.

Although this is the current behavior of dataclass, I haven't found it documented anywhere and the behavior is not covered by unit tests. Since dataclass_transform wants to rely on this behavior and the behavior seems desirable for dataclass as well, I'm proposing that we add additional dataclass unit tests to ensure that this behavior does not change in the future.

Specifically, we would like to document (and add unit tests for) the following behavior given a field whose default value is a descriptor:

1. The value passed to __init__ for that field is passed to the descriptor?s __set__ method, rather than overwriting the descriptor object.

2. Getting/setting the value of that field goes through __get__/__set__, rather than getting/overwriting the descriptor object.

Here's an example:

class Descriptor(Generic[T]):
    def __get__(self, __obj: object | None, __owner: Any) -> T:
        return getattr(__obj, "_x")

    def __set__(self, __obj: object | None, __value: T) -> None:
        setattr(__obj, "_x", __value)

@dataclass
class InventoryItem:
    quantity_on_hand: Descriptor[int] = Descriptor[int]()

i = InventoryItem(13)     # calls __set__ with 13
print(i.quantity_on_hand) # 13 -- obtained via call to __get__
i.quantity_on_hand = 29   # calls __set__ with 29
print(i.quantity_on_hand) # 29 -- obtained via call to __get__

I took a first stab at unit tests here: https://github.com/debonte/cpython/commit/c583e7c91c78c4aef65a1ac69241fc06ad95d436

We are aware of two other descriptor-related behaviors that may also be worth documenting:

First, if a field is annotated with a descriptor type but is *not* assigned a descriptor object as its default value, it acts like a non-descriptor field. Here's an example:

@dataclass
class InventoryItem:
    quantity_on_hand: Descriptor[int] # No default value

i = InventoryItem(13)      # Sets quantity_on_hand to 13 -- No call to Descriptor.__set__
print(i.quantity_on_hand)  # 13 -- No call to Descriptor.__get__

And second, when a field with a descriptor object as its default value is initialized (when the code for the dataclass is initially executed), __get__ is called with a None instance and the return value is used as the field's default value. See the example below. Note that if __get__ doesn't handle this None instance case (for example, in the initial definition of Descriptor above), a call to InventoryItem() fails with "TypeError: InventoryItem.__init__() missing 1 required positional argument: 'quantity_on_hand'".

I'm less sure about documenting this second behavior, since I'm not sure what causes it to work, and therefore I'm not sure how intentional it is.

class Descriptor(Generic[T]):
    def __init__(self, *, default: T):
        self._default = default

    def __get__(self, __obj: object | None, __owner: Any) -> T:
        if __obj is None:
            return self._default

        return getattr(__obj, "_x")

    def __set__(self, __obj: object | None, __value: T) -> None:
        if __obj is not None:
            setattr(__obj, "_x", __value)

# When this code is executed, __get__ is called with __obj=None and the
# returned value is used as the default value of quantity_on_hand.
@dataclass
class InventoryItem:
    quantity_on_hand: Descriptor[int] = Descriptor[int](default=100)

i = InventoryItem()       # calls __set__ with 100
print(i.quantity_on_hand) # 100 -- obtained via call to __get__

----------
components: Library (Lib)
messages: 416392
nosy: JelleZijlstra, debonte, eric.smith
priority: normal
severity: normal
status: open
title: Define behavior of descriptor-typed fields on dataclasses
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed Mar 30 17:28:38 2022
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 30 Mar 2022 21:28:38 +0000
Subject: [New-bugs-announce] [issue47175] Allow applications to tune the
 condition that triggers a GIL release and implementation choice in hashlib
Message-ID: <1648675718.75.0.491901512774.issue47175@roundup.psfhosted.org>


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

## Background

All `hashlib` computations and `binascii.crc32` and `zlib.crc32` release the GIL around their computational core.  But they use a hard coded length check to determine when to do so, or always do it.

That already accomplishes the larger good of releasing the GIL on big computations. But _probably_ just serves to slow down smaller ones when a GIL release adds more overhead than a context switch to another thread could meaningfully provide in terms of forward progress.

## Desire 1

Determine if a threshold should exist at all (should we just always release the GIL for these?) and if so, allow it to be tuned on a per algorithm basis.

This comes at the same time as other enhancements like bpo-47102 and its windows and macos cousins could shift us towards using OS kernel APIs for a subset of algorithms where available - which may effectively "always release" the GIL on OS APIs that are virtual IO call based such as bpo-47102's.

## Desire 2

When multiple implementations of an algorithm may be available, allow the user to configure data length thresholds for when each one is triggered. Without meaningfully slowing most things down by adding such logic.  Different implementations have different setup and finalization time which can make them more useful for large data rather than tiny.

---

I'm marking this low priority as it veers towards over-optimization. :)  Creating benchmarks and a thing to live in Tools/ that people could run on their target platform to provide a tuning suggestion of what thresholds work best for their needs.

Related inspiring work: OSes often benchmark several algorithm implementations up front to pick a "best" to use for a given platform (ex: see what the Linux kernel does for hashes and raid algorithms).  This extends that idea and acknowledges latency as important, not exclusively thru-put.

----------
messages: 416401
nosy: gregory.p.smith
priority: low
severity: normal
stage: needs patch
status: open
title: Allow applications to tune the condition that triggers a GIL release and implementation choice in hashlib
type: enhancement

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

From report at bugs.python.org  Wed Mar 30 17:55:22 2022
From: report at bugs.python.org (Hood Chatham)
Date: Wed, 30 Mar 2022 21:55:22 +0000
Subject: [New-bugs-announce] [issue47176] Interrupt handling for
 wasm32-emscripten builds without pthreads
Message-ID: <1648677322.27.0.607778743764.issue47176@roundup.psfhosted.org>


New submission from Hood Chatham <roberthoodchatham at gmail.com>:

In Pyodide, we need to patch the interpreter to allow keyboard interrupts. We build Python without pthreads support because Emscripten doesn't currently support using pthreads and dynamic linking in the same build. It is still possible to handle UI at the same time as running Python code by running Python in a web worker. However, the web assembly memory is private to the webworker and cannot be modified from the main thread. The standard way that keyboard interrupts are handled is that the operating system preempts the task to run a signal handler. This can't happen in Emscripten because there is no operating system.

Instead, in Emscripten we create a SharedArrayBuffer, share it with the main thread, and then write the signal into this shared memory from the main thread. We patch the main loop to periodically poll this SharedArrayBuffer and if an interrupt has been requested it calls `PyErr_SetInterruptEx` to signal the interrupt. I've set the polling rate to once every 50 interpreter operations, which seems to be reasonably responsive and have a negligible performance cost. 

One interesting feature of this setup is that it is impossible to create a pointer to the shared memory so it cannot be read directly from C (instead we check it from an `EM_ASM` block).

----------
components: Interpreter Core
messages: 416403
nosy: hoodmane
priority: normal
severity: normal
status: open
title: Interrupt handling for wasm32-emscripten builds without pthreads
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Mar 30 21:12:26 2022
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 31 Mar 2022 01:12:26 +0000
Subject: [New-bugs-announce] [issue47177] Frames should store next_instr
 instead of lasti
Message-ID: <1648689146.75.0.35492797482.issue47177@roundup.psfhosted.org>


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

Rather than maintaining the offset of the "last instruction" (`f_lasti`), interpreter frames should instead just maintain a pointer to the true next instruction. This has several benefits, most notably reducing the register pressure associated with loading first_instr on every instruction and call in the main interpreter loop:

When entering a frame:

- Before: `next_instr = first_instr + frame->f_lasti + 1;`
- After:  `next_instr = frame->next_instr;`

When starting a new instruction:

- Before: `frame->next_instr = next_instr++ - first_instr;`
- After:  `frame->next_instr = ++next_instr;`

Benchmarks suggest that this overhead is surprisingly significant (something like 2%).

----------
assignee: brandtbucher
components: Interpreter Core
messages: 416409
nosy: Mark.Shannon, brandtbucher
priority: normal
severity: normal
stage: patch review
status: open
title: Frames should store next_instr instead of lasti
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 31 01:38:23 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 31 Mar 2022 05:38:23 +0000
Subject: [New-bugs-announce] [issue47178] Improve the implementations of
 Sequence.index and MutableSequence.extend in collections.abc
Message-ID: <1648705103.72.0.31480017393.issue47178@roundup.psfhosted.org>


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

This P.R. will make the following changes to the `collections.abc` module:

- simplify the implementation with slicing in function `Sequence.index`.
- remove an unnecessary copy of `self` when a sequence extends itself in function `MutableSequence.extend`.

----------
components: Library (Lib)
messages: 416415
nosy: maggyero
priority: normal
pull_requests: 30285
severity: normal
status: open
title: Improve the implementations of Sequence.index and MutableSequence.extend in collections.abc
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Mar 31 04:59:44 2022
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 31 Mar 2022 08:59:44 +0000
Subject: [New-bugs-announce] [issue47179] pymalloc should align to
 max_align_t
Message-ID: <1648717184.73.0.9591468393.issue47179@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

malloc() returns memory that's "suitably aligned for any built-in type".
All of Python's allocation functions should do the same. 

In bpo-27987 (PR-12850, PR-13336), the alignment was raised* to 16 bytes and `long double`. This is OK for current architectures, so there is no practical issue right now.

But, C11 defines a [max_align_t] type which sounds like the *correct* thing to use for determining pymalloc/PyGC_Head alignment.
At least we should assert that obmalloc's ALIGNMENT is a multiple of `alignof(max_align_t)`, and use max_align_t rather than `long double` in PyGC_Head.



See also this python-cffi issue: https://foss.heptapod.net/pypy/cffi/-/issues/531#note_181779

[max_align_t]: https://en.cppreference.com/w/c/types/max_align_t

* (on 64-bit arches)

----------
components: C API
messages: 416421
nosy: methane, petr.viktorin, pitrou, vstinner
priority: normal
severity: normal
status: open
title: pymalloc should align to max_align_t

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

From report at bugs.python.org  Thu Mar 31 05:34:33 2022
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Thu, 31 Mar 2022 09:34:33 +0000
Subject: [New-bugs-announce] [issue47180] Remove unnecessary registration of
 weakref.WeakSet as a subtype of _collections_abc.Set
Message-ID: <1648719273.79.0.963902821891.issue47180@roundup.psfhosted.org>


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

Registering `weakref.WeakSet` as a subtype of `_collections_abc.MutableSet` implies that it is also a subtype of `_collections_abc.Set` since `_collections_abc.MutableSet` is a subtype of `_collections_abc.Set` and the subtype relation is transitive.

----------
components: Library (Lib)
messages: 416422
nosy: maggyero
priority: normal
pull_requests: 30287
severity: normal
status: open
title: Remove unnecessary registration of weakref.WeakSet as a subtype of _collections_abc.Set
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu Mar 31 05:56:37 2022
From: report at bugs.python.org (gerald honk)
Date: Thu, 31 Mar 2022 09:56:37 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue47181=5D_error=3A_impossib?=
 =?utf-8?b?bGUgY29uc3RyYWludCBpbiDigJhhc23igJk=?=
Message-ID: <1648720597.59.0.268868863694.issue47181@roundup.psfhosted.org>


New submission from gerald honk <glynnis.honk at gmail.com>:

On CentOS7 gcc 4.8.5 compiler
it dosen't work
run
./configure --enable-ipv6 --enable-shared --with-dbmliborder=gdbm:ndbm:bdb   --with-computed-gotos=yes  --with-system-expat   --with-system-ffi --enable-loadable-sqlite-extensions --with-dtrace  --with-lto  --with-ssl-default-suites=openssl --enable-optimizations

error: impossible constraint in ?asm?

----------
components: Build
messages: 416423
nosy: glynnis.honk
priority: normal
severity: normal
status: open
title: error: impossible constraint in ?asm?
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Thu Mar 31 09:34:15 2022
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 31 Mar 2022 13:34:15 +0000
Subject: [New-bugs-announce] [issue47182] _PyUnicode_Fini should invalidate
 ucnhash_capi capsule pointer
Message-ID: <1648733655.32.0.129667440403.issue47182@roundup.psfhosted.org>


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

unicodeobject.c has a static pointer to a unicode name CAPI capsule:

   static _PyUnicode_Name_CAPI *ucnhash_capi = NULL;

The capsule is initialized on demand when the parser encounters a named unicode representation like "\N{digit nine}". Once the capsule pointer ucnhash_capi has been initialized, it is never reset. Not even a full interpreter shutdown invalidates the pointer.

A shutdown of the main interpreter with Py_Finalize() renders the pointer invalid. If the interpreter is re-initialized again, the invalid pointer causes a segfault. The problem was first discovered by Trey Hunner in https://github.com/ethanhs/python-wasm/issues/69

python.js:219 Uncaught RuntimeError: null function or function signature mismatch
    at _PyUnicode_DecodeUnicodeEscapeInternal (unicodeobject.c:6493:25)
    at decode_unicode_with_escapes (string_parser.c:121:13)
    at _PyPegen_parsestr (string_parser.c:273:1)
    at strings_rule (action_helpers.c:901:20)
    at atom_rule (parser.c:14293:27)
    at primary_rule (parser.c:13916:17)
    at await_primary_rule (parser.c:13666:17)
    at factor_rule (parser.c:13542:29)
    at term_rule (parser.c:13330:17)
    at sum_rule (parser.c:13044:17)

I can reproduce the issue with pure C code:

$ gcc -Xlinker -export-dynamic -g -IInclude/ -I. -o ucnbug ucnbug.c libpython3.11.a -lm -ldl
$ gdb ucnbug
(gdb) run
0
9
Done

1

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000005729a8 in _PyUnicode_DecodeUnicodeEscapeInternal (s=<optimized out>, s at entry=0x7fffea53b6d0 "\\N{digit nine}", size=<optimized out>, errors=errors at entry=0x0, 
    consumed=consumed at entry=0x0, first_invalid_escape=first_invalid_escape at entry=0x7fffffffc748) at Objects/unicodeobject.c:6490
#2  0x0000000000644fe3 in decode_unicode_with_escapes (parser=parser at entry=0x7fffea5e45d0, s=0x7fffea53b6d0 "\\N{digit nine}", s at entry=0x7fffea6af1d1 "\\N{digit nine}'", len=<optimized out>, 
    len at entry=14, t=t at entry=0x7fffea606910) at Parser/string_parser.c:118
#3  0x0000000000645675 in _PyPegen_parsestr (p=p at entry=0x7fffea5e45d0, bytesmode=bytesmode at entry=0x7fffffffc838, rawmode=rawmode at entry=0x7fffffffc83c, result=result at entry=0x7fffffffc848, 
    fstr=fstr at entry=0x7fffffffc850, fstrlen=fstrlen at entry=0x7fffffffc858, t=0x7fffea606910) at Parser/string_parser.c:269
#4  0x0000000000644163 in _PyPegen_concatenate_strings (p=p at entry=0x7fffea5e45d0, strings=strings at entry=0x94e310) at Parser/action_helpers.c:896
#5  0x00000000004791e6 in strings_rule (p=p at entry=0x7fffea5e45d0) at Parser/parser.c:15463
#6  0x000000000047c498 in atom_rule (p=p at entry=0x7fffea5e45d0) at Parser/parser.c:14274
#7  0x000000000047e159 in primary_raw (p=0x7fffea5e45d0) at Parser/parser.c:13908
#8  primary_rule (p=p at entry=0x7fffea5e45d0) at Parser/parser.c:13706

----------
components: Interpreter Core
files: ucnbug.c
messages: 416432
nosy: christian.heimes, lukasz.langa, pablogsal, vstinner
priority: high
severity: normal
status: open
title: _PyUnicode_Fini should invalidate ucnhash_capi capsule pointer
type: crash
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50708/ucnbug.c

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

From report at bugs.python.org  Thu Mar 31 12:17:03 2022
From: report at bugs.python.org (mike mcleod)
Date: Thu, 31 Mar 2022 16:17:03 +0000
Subject: [New-bugs-announce] [issue47183] Cant compile html docs
Message-ID: <1648743423.29.0.273944494848.issue47183@roundup.psfhosted.org>


New submission from mike mcleod <mikecmcleod at gmail.com>:

After sync'ing to upstream/main and then
python/Doc on ? main via ? v3.11.0a6+ 
? make html
mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees   -W . build/html 
Running Sphinx v3.5.4
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 495 source files that are out of date
updating environment: [new config] 495 added, 0 changed, 0 removed
reading sources... [100%] whatsnew/index                                        
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... failed

Warning, treated as error:
unsupported theme option 'license_url' given
make: *** [Makefile:53: build] Error 2

No changes to source.

----------
assignee: docs at python
components: Documentation
messages: 416448
nosy: docs at python, mikecmcleod
priority: normal
severity: normal
status: open
title: Cant compile html docs
type: compile error
versions: Python 3.11

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

From report at bugs.python.org  Thu Mar 31 13:42:20 2022
From: report at bugs.python.org (John Hagen)
Date: Thu, 31 Mar 2022 17:42:20 +0000
Subject: [New-bugs-announce] [issue47184] multiprocessing.set_start_method
 force argument is not documented
Message-ID: <1648748540.61.0.562743506466.issue47184@roundup.psfhosted.org>


New submission from John Hagen <johnthagen at gmail.com>:

multiprocessing.set_start_method() has a `force` argument that is not documented: https://docs.python.org/3.10/library/multiprocessing.html#multiprocessing.set_start_method

----------
assignee: docs at python
components: Documentation
messages: 416451
nosy: John Hagen, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.set_start_method force argument is not documented
type: enhancement
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/issue47184>
_______________________________________