> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
