[Python-Dev] New _Py_InitializeFromConfig() function (PEP 432)

[Nick Coghlan]

On 3 August 2018 at 01:59, Victor Stinner <vstinner at redhat.com> wrote:
> 2018-08-02 1:18 GMT+02:00 Eric Snow <ericsnowcurrently at gmail.com>:
>> The "core" config is basically the config for the runtime.  In fact,
>> PEP 432 renamed "core" to "runtime".  Please keep the firm distinction
>> between the runtime and the (main) interpreter.
>
> There is already something called _PyRuntime but it's shared between
> all interpreters.
>
> _PyCoreConfig is already *per* interpreter.
>
> Would you mind to elaborate what you mean by the "main interpreter"? I
> don't see anything obvious in the current code about what is a "main
> interpreter". Technically, I don't see anything like that.
>
> I'm still not convinced that we need _PyMainInterpreterConfig:
> _PyCoreConfig contains the same information. Is it really worth it to
> duplicate all _PyCoreConfig (more than 36 fields) in
> _PyMainInterpreterConfig? _PyMainInterpreterConfig adds a third copy
> of many paramters: another opportunity to introduce an inconsistency.
> Right now, an interpreter contains both: core and main
> configurations...

The issue is massive scope creep in the "core config": currently you
need to fully specify everything in order to even use the builtin data
structs. That's not the design goal of PEP 432: the idea is to have an
absolutely bare minimum set of settings that gives a working C API,
but won't let you access the host operating system.

I wasn't reigning you in on it because there were real problems to be
solved in getting the multi-stage start up to work at all given the
current code structure.

Now that it's working though, we should be looking to move settings
back out of coreconfig, and reducing the amount of startup work that
needs to be done using raw C code that can't rely on the CPython C
API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia