This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author petr.viktorin
Recipients erlendaasland, pablogsal, petr.viktorin, rhettinger, shihai1991
Date 2021-10-23.11:00:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Quoting PEP 630 (active PEP):
>   Whenever this PEP mentions extension modules, the advice also applies to
>   built-in modules, such as the C parts of the standard library. The standard
>  library is expected to switch to per-module state early.

Maybe I should remove that part, I didn't expect applying this to stdlib would be so fast/rushed.

> Can you please point me to the official SC statement regarding this? I cannot find it.

Hmm, the best I can find is
It asks for no changes in 3.10 beta (no longer relevant) and a PEP -- presumably one specifically for the stdlib; PEP 630 already existed.

PEP 630 works best for new code; applying it to stdlib needs additional considerations, e.g. performance impact analysis, and preserving immutability or (un)pickleability, which certainly wasn't always tested well and caused much trouble late tn the release cycle.

> Please get explicit approval from the SC before continuing to sweep through the code base, creating heap types everywhere.

That would be nice (but myself, I won't be championing that effort any time soon).

> Given that some essential third party modules are not going down this path

OTOH, others (like cryptography & Qt) are going down this path, so I'll continue improving the support.
Date User Action Args
2021-10-23 11:00:18petr.viktorinsetrecipients: + petr.viktorin, rhettinger, pablogsal, shihai1991, erlendaasland
2021-10-23 11:00:18petr.viktorinsetmessageid: <>
2021-10-23 11:00:18petr.viktorinlinkissue45113 messages
2021-10-23 11:00:18petr.viktorincreate