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 (asPy_NewInterpreterFromConfig()).

My plan:

1. change the argument to a new_PyInterpreterConfig struct
2. rename the function toPy_NewInterpreterFromConfig(), inspired byPy_InitializeFromConfig() (takes aPyInterpreterConfig instead ofisolated_subinterpreter)
3. split up the booleanisolated_subinterpreter into the corresponding multiple granular settings
   • allow_fork
   • allow_subprocess
   • allow_threads
4. dropPyConfig._isolated_interpreter

Note that the current default (Py_NewInterpeter() andPy_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. dropPyInterpreterConfig.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