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

Victor Stinner vstinner at redhat.com
Thu Aug 2 11:54:00 EDT 2018

2018-08-02 17:17 GMT+02:00 Eric Snow <ericsnowcurrently at gmail.com>:
> Note that there are backward compatibility issues to deal with.  AFAIU
> if we start ignoring those global variables during initialization then
> it's going to cause problems for embedders.

One of the first operation of Py_Initialize(), Py_Main() and
_PyCoreConfig_Read() is to get the current value of all global
configuration variables.

The change is more that modifying a global configuration variable
after Py_Initialize() or Py_Main() may or may not have an effect. And
in the future, it should no longer have effect. In short, these
variables should only be read to populate the initialization
configuration and then it should no longer change.

> So I'm guessing you planned on deprecating any use of those global variables
> and, in the spirit of your goals for the C-API, provide a public API
> for extensions to access the info in the runtime config instead.

There is no *need* to deprecate anything. _PyCoreConfig remains fully
compatible with them and there are now unit tests to make sure that
their value is read at Python startup.

The priority is: core config > global vars > env vars.

>> But I'm also trying to make sure that the two variables have the same value:
>> https://github.com/python/cpython/commit/a4d20b2e5ece2120f129cb4dda951a6c2461e92d
> Yep.  That is necessary while the global config variables still exist.
> It's just risky since it's easy for us to change the config but forget
> to update the global config vars (that are shadowing the config).  It
> would probably be worth making sure we have tests that verify that the
> two stay synchronized.

If possible, I would prefer that the configuration is *not* modified
after Python has been initialized. I even hesitate to mark
PyInterpreterState.core_config a constant to prevent such change.

The idea would be to know exactly how Python has been initialize, to
make the initialization more deterministic and explicit.

To come back to a concrete example:

We can easily modify core_config->inspect before Python
initialization. For this commit, it's just that I wanted to make tiny
and incremental changes.


More information about the Python-Dev mailing list