[issue46964] The global config should not be stored on each interpreter

STINNER Victor added the comment: > If the invariant bits are moved out, then it clearly indicates when code can > safely assume that every interpreter will be seeing the same value. What is the benefit of that? Do you have an example? -- ___ Pyth

[issue46964] The global config should not be stored on each interpreter

Nick Coghlan added the comment: I agree the status quo has its benefits. However, it has the distinct downside that because each interpreter has its own storage for copied settings, other code has to assume the settings *might* be different in each interpreter, even if they're currently alwa

[issue46964] The global config should not be stored on each interpreter

STINNER Victor added the comment: > Moving the invariant bits would certainly make sense. IMO it's convenient to have a single structure for all "configuration", even if a few parameters are expected to be the same in all interpreters. Python/initconfig.c is already a long C file. It contain

[issue46964] The global config should not be stored on each interpreter

Nick Coghlan added the comment: Moving the invariant bits would certainly make sense. As Victor notes, though, some things (like whether to install the signal handlers) should be different. -- ___ Python tracker

[issue46964] The global config should not be stored on each interpreter

STINNER Victor added the comment: > thus far we have had no actual use cases for initializing an interpreter > with a different config I don't think that sub-interpreters should have config.install_signal_handlers=1. Same for config.configure_c_stdio=1. Only the main interpreter should hand

[issue46964] The global config should not be stored on each interpreter

Eric Snow added the comment: Here are reasons why PyConfig relates to the runtime and not each interpreter: * PyConfig was introduced so embedders could dictate how the *runtime* should be initialized * after initialization, it represents how the runtime was initialized * in the public API,

[issue46964] The global config should not be stored on each interpreter

STINNER Victor added the comment: > Doing so unnecessarily adds extra complexity (and, when multiple interpreters > are used, extra CPU usage and extra memory usage). Right, PyConfig allocates memory per interpeter. But IMO it's an acceptable trade-off. I don't see the benefits of sharing th

[issue46964] The global config should not be stored on each interpreter

Change by Eric Snow : -- keywords: +patch pull_requests: +29879 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31771 ___ Python tracker ___

[issue46964] The global config should not be stored on each interpreter

New submission from Eric Snow : tl;dr let's move PyInterpreterState.config to _PyRuntimeState.config. Historically the runtime has been initialized using Py_Initialize(). PEP 587 added Py_InitializeFromConfig(), which takes a PyConfig and allows all sorts of customization of the runtime. Th