For now, in a future PR this can be changed.

See also my note in#29025 (comment). Briefly, I was mistaken in my understanding of the documentation,-1 is only valid for single-phase initialisation, and is forbidden for multi-phase.

The safest thing reinitialisation-wise would be to use themultiple interpreter opt-out suggested by CPython. This would enforce that each extension module is only imported & initialised once per process.

However, this causestest_reloading.py::test_full_reimport() to fail. Is that an acceptable trade-off? Multi-phase init (and at some point, isolated modules) opens the door to proper support for reloading/reimportingnumpy.

cc@encukou re the best way to do a gradual migration to multi-phase

In the case ofumath_linalg, we might be fine globals-wise, butmultiarray will definitely need a solution here.

I'vejust updated the HOWTO, seehere before it gets to main docs.

Basically, to allow re-import, clear the "loaded" flag inPyModuleDef'sm_clear. Note that thiswill do an actual reload of the module (sans C globals), that is,exec will run. (With single-phase, the module dict contents are stashed away and reused. You could emulatethat, but )

The PyMutex stuff in the updated HOWTO is 3.13+ non-limited API, but isn't necessary in the medium term (on CPython you're protected by the GIL; even free-threading builds use an import lock which isn't likely to go away). For the long-term (or alternate CAPI implementations) you could add no-op shims.

ThePy_MOD_MULTIPLE_INTERPRETERS_NOT_SUPPORTED flag will only allow loading in the main interpreter; that's redundant if you're limited to one module per process.

However, this causes test_reloading.py::test_full_reimport() to fail. Is that an acceptable trade-off?

I am not opposed to breaking the test/changing the behavior. The ask would be to summarize how things change for:

• Potentialsubinterpreter users (Ithink that just doesn't work at all anymore, but not sure).
• Users forimportlib.reload(), currently they get a warning that this is a bad idea. A full-blown error may not be so bad, though.