Petr Viktorin <encu...@gmail.com> added the comment:

> 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 
https://github.com/python/steering-council/blob/main/updates/2021-02-steering-council-update.md#february-08
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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45113>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to