gh-80406: Finalise subinterpreters in Py_FinalizeEx() by LewisGaul · Pull Request #17575 · python/cpython

On Sat., 25 Jan. 2020, 7:45 am Eric Snow, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In Include/internal/pycore_pystate.h <#17575 (comment)>: > @@ -226,6 +226,7 @@ typedef struct pyruntimestate { If that becomes a problem later then we can adjust, e.g. by using a Python int. */ int64_t next_id; + int finalizing; I guess it's a bit vague. "new" what? Honestly, the flag represents more than just the availability of subinterpreters. So I'd probably feel more comfortable with "ready" (or "available"), which would mean "the full capability of the C-API is available" (including subinterpreters). @ncoghlan <https://github.com/ncoghlan>, what do you think?

My expectation with the naming suggestion is that we use the flag to mean "`Py_NewInterpreter` will now work". It's true it could be seen as ambiguous with the more general meaning "allow new objects" (based on the name of the tp_new slot and associated Python magic method), so I'd also be OK with expanding it to be the more explicit "allow_new_interpreters". I don't think we'd be helping anyone by making the flag itself ambiguous, though, so I think we should stick with the concrete meaning of "`Py_NewInterpreter` will always fail immediately when this is not set".