PEP 489 introduced multiphase initialization of extension and built-in modules.
Now, almost no module in the standard library supports this feature. This should be improved to prepare Python for better testing of subinterpreters.

Many benefits of PEP 489 don't apply to stdlib modules. However, the PEP effectively says that by using multi-phase init, the module author "promises" that the module is "subinterpreter-friendly" [0]. So, when porting, each module should be checked that it e.g. doesn't use mutable process-global state.

I'd like to port stdlib to multi-phase init, starting with the easier modules, to:
    - get familiar with contributing to CPython,
    - check and track which modules are already "subinterpreter-friendly", and
    - figure out how and where PEP 489 is lacking (beyond what is discussed in the PEP itself).


[0]: https://www.python.org/dev/peps/pep-0489/#subinterpreters-and-interpreter-reloading

FWIW, Marcel is an intern in my team, tasked to learn CPython internals by trying to improve subinterpreter support. If I don't comment on his issues it's because we discussed privately beforehand.

New changeset 33e71e01e95506cf8d93fd68251fc56352bc7b39 by Petr Viktorin (Marcel Plch) in branch 'master':
bpo-31862: Port binascii to PEP 489 multiphase initialization (GH-4108)
https://github.com/python/cpython/commit/33e71e01e95506cf8d93fd68251fc56352bc7b39

I marked bpo-15681 "PEP 3121 refactoring applied to binascii module" as a duplicate of this issue.

See also bpo-1635741 "Py_Finalize() doesn't clear all Python objects at exit": many extension modules have been ported to multi-phase initialization API (PEP 489) there.

I prefer to track the work in a single issue. Even if bpo-1635741 contains many unrelated changes, I prefer to continue to use bpo-1635741 to track the work on "porting the standard library to PEP 489 multiphase initialization".