Feature or enhancement

We make a bunch of accommodations for the "main" (initial) interpreter, especially during initialization and finalization. This adds complexity to the runtime. We should consider making the main interpreter (mostly) not special. At most we need to specifically special-case relative to the main thread.

The main thread of a Python program uses the initial thread state of the main interpreter. That thread is special for the following reasons, at least for the Python executable (and for some embedding cases):

• where the main code of the app executes
• where the REPL runs
• where signal handlers run
• where the main (initial) interpreter is always created
• (usually) where runtime finalization happens

Thus the initial thread state of the main interpreter plays a critical role. The code reflects this, especially in Python/pylifecycle.c. However, a lot of the special treatment of the main interpreter is unnecessary. ¹

The main interpreter is the one created during runtime initialization and used during initialization. This is relevant for any non-immortal, non-static objects that we store on _PyRuntimeState, which we should strenuously avoid doing anyway. It is likely also relevant for embedders.

There are also a couple of places where the "main" interpreter needs to be factored in (which we currently isn't), but doesn't necessarily need to be addressed with this issue:

• runtime finalization should happen in the main thread, with the main interpreter?
• os.fork() should update the main thread state and the main interpreter (or only be allowed in the main thread of the main interpreter)?

CC @markshannon, @vstinner, @ncoghlan, @zooba