This issue became a blocker issue while working on bpo-39984, when I tried to move pending calls from _PyRuntimeState to PyInterpreterState.

I wrote PR 19063 to deny calling Py_FinalizeEx() from a subinterpreter.


Eric:
> On the other hand, if the "main" interpreter isn't special after runtime init is done (i.e. a subinterpreter is effectively indistinguishable by nature) then it certainly would not matter which one finalizes (or is active during fork() for that matter).  On top of that, the effort we are making to identify the main interpreter (both in the code and in the docs) becomes unnecessary.

Well. Maybe we will be able to reach this point later, but right now, there are concrete implementation issues. The main interpreter remains special. Only the main interpreter is allowed to call fork(), spawn daemon threads, handle signals, etc.

If we manage to make subinterpreters less special, we can change Py_FinalizeEx() again later.


I asked:
> Is Python supposed to magically destroy the 3 interpreters?

Currently, Py_FinalizeEx() fails with a fatal error if there are remaining subinterpreters:
---
Fatal Python error: PyInterpreterState_Delete: remaining subinterpreters
Python runtime state: finalizing (tstate=0xfaa1c0)

Abandon (core dumped)
---

IMHO it's a good behavior.

if we want, we can modify Py_FinalizeEx() to magically end subinterpters later. The opposite may be more annoying for embedders.