Expose _Py_NewInterpreter() as Py_NewInterpreterFromConfig() · Issue #98608 · python/cpython (original) (raw)

A while back I added _Py_NewInterpreter() (a "private" API) to support configuring the new interpreter. Ultimately, I'd like to adjust
the signature a little and then make the function part of the public API (as Py_NewInterpreterFromConfig()).

My plan:

1. change the argument to a new _PyInterpreterConfig struct
2. rename the function to Py_NewInterpreterFromConfig(), inspired by Py_InitializeFromConfig() (takes a PyInterpreterConfig instead of isolated_subinterpreter)
3. split up the boolean isolated_subinterpreter into the corresponding multiple granular settings
   • allow_fork
   • allow_subprocess
   • allow_threads
4. drop PyConfig._isolated_interpreter

Note that the current default (Py_NewInterpeter() and Py_Initialize*()) allows fork, subprocess, and threads, and the optional "isolated" interpreter disables all three. I'm not planning on changing any of that here.

My main objective here is to expose the existing API in a way that we can do the following afterward:

• stop giving the option to disallow subprocess (i.e. drop PyInterpreterConfig.allow_subprocess)
• add an option to disallow just "exec" instead
• stop disallowing threads as a default behavior for an "isolated" interpreter (we'd still keep the option though)
• add the option to disallow daemon threads
• add an option to check if each extension supports running in multiple interpreters
• add other options for PEP 684 (per-interpreter GIL)

Linked PRs

• gh-98608: Stop Treating All Errors from _Py_NewInterpreterFromConfig() as Fatal #102657
• gh-98608: Fix Failure-handling in new_interpreter() #102658
• [3.11] gh-98608: Fix Failure-handling in new_interpreter() (gh-102658) #102882
• [3.10] gh-98608: Fix Failure-handling in new_interpreter() (gh-102658) #102883
• gh-98608: Move PyInterpreterConfig to pylifecycle.h #107191
• [3.12] gh-98608: Move PyInterpreterConfig to pylifecycle.h (GH-107191) #107198