osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] New Python Initialization API


> I think my biggest point (about halfway down) is that I'd rather use
> argv/environ/etc. to *initialize* PyConfig and then only use the config
> for initializing the runtime. That way it's more transparent for users
> and more difficult for us to add options that embedders can't access.

I chose to exclude PyConfig_Read() function from the PEP to try to start
with the bare minimum public API and see how far we can go with that.

The core of the PEP 587 implementation are PyPreConfig_Read() and
PyConfig_Read() functions (currently called _PyPreConfig_Read() and
_PyCoreConfig_Read()): they populate all fields so the read config becomes
the reference config which will be applied.

For example, PyConfig_Read() fills module_search_paths, from other
PyConfig fields: it will become sys.path.

I spent a lot of time to rework deeply the implementation of
PyConfig_Read() to make sure that it has no side effect. Reading and
writing the configuration are now strictly separated. So it is safe
to call PyConfig_Read(), modify PyConfig afterwards, and pass the modified
config to Py_InitializeFromConfig().

Do you think that exposing PyConfig_Read() would solve some of your
problems?


> Currently you have three functions, that take a PyConfig and optionally
> also use the environment/argv to figure out the settings:
>
> > * ``PyInitError Py_InitializeFromConfig(const PyConfig *config)``
> > * ``PyInitError Py_InitializeFromArgs(const PyConfig *config, int
> argc, char **argv)``
> > * ``PyInitError Py_InitializeFromWideArgs(const PyConfig *config, int
> argc, wchar_t **argv)``
>
> I would much prefer to see this flipped around, so that there is one
> initialize function taking PyConfig, and two functions that will fill
> out the PyConfig based on the environment:
>
> (note two of the "const"s are gone)
>
> * ``PyInitError Py_SetConfigFromArgs(PyConfig *config, int argc, char
> **argv)``
> * ``PyInitError Py_SetConfigFromWideArgs(PyConfig *config, int argc,
> wchar_t **argv)``
> * ``PyInitError Py_InitializeFromConfig(const PyConfig *config)``

This implementation evolved *A LOT* last months. I was *very confused*
until the pre-initialization phase was introduced which solved a lot
of bootstrap issues.

After I wrote down the PEP and read it again, I also came to the same
conclusion: Py_InitializeFromConfig(config) should be enough, and we can
add helper functions to set arguments on PyConfig (as you showed).

Victor