[Python-Dev] PEP 587 "Python Initialization Configuration" version 4

[Victor Stinner]

Hi,

Le lun. 20 mai 2019 à 21:36, Antoine Pitrou <solipsis at pitrou.net> a écrit :
> - Since PyInitError can be "ok", I'd rather call it "PyInitStatus".

Oh, I like this name :-)

By the way, I'm not comfortable with "PyInitError_Failed()" name since
it's true if it's an error (failure) ... or "an exit". What do you
think of the name "PyInitStatus_IsDone()"? It would give the pattern:

PyInitStatus status = Py_InitializeFromConfig(&config);
if (PyInitStatus_IsDone(status)) {
    PyConfig_Clear(&config);
    Py_ExitInitStatus(status);
}

Does it make more sense than the current code below?

PyInitError err = Py_InitializeFromConfig(&config);
if (PyInitError_Failed(err)) {
    PyConfig_Clear(&config);
    Py_ExitInitError(err);
}


> - The PyConfig example sets "module_search_paths" but not
>   "module_search_paths_set".  Is it an error?

If "module_search_paths_set" is set to 1, PyConfig_Read() leaves
"module_search_paths" unchanged. So it becomes possible to use Python
with sys.path = [].

Extract of the mentioned example (simplified):
---
PyConfig_Read(&config);
PyWideStringList_Append(&config.module_search_paths, L"/path/to/more/modules");
---

PyConfig_Read() is responsible to set "module_search_paths_set" to 1.
So if PyConfig_Read() is called again (which is always the case in
Py_InitializeFromConfig() to ensure that all PyConfig fields are set),
our customized module_search_paths is preserved.


> - "PyConfig_InitPythonConfig" vs "PyConfig_InitIsolatedConfig": why not
>   "PyConfig_InitConfig" and "PyConfig_InitIsolatedConfig"?

You should read "PyConfig_InitPythonConfig" as: same configuration
than regular Python executable.

Python 3.7 Py_Initialize() doesn't provide you exactly the same
configuration than regular Python executable: command line arguments
of sys.argv are not parsed, C standard streams are not configured,
etc.

Moreover, maybe someone will come up with a 3rd flavor of config, so I
prefer to give them explicit names ;-)

A single default configuration doesn't fit with all use cases, so PEP
587 provides two different flavors :-)


> - Why is there an "isolated" field in addition to the "IsolatedConfig"
>   functions?

There is a single PyConfig structure in the API. It makes more sense
for the Python Configuration which is *not* isolated by default. So
you can opt-in for an isolated Python configuration, as shown in the
example:
https://www.python.org/dev/peps/pep-0587/#python-configuration

Moreover, well, I have to store the information somewhere :-)

The idea of the "Isolated Configuration" is to start from the most
isolated configuration, but then to can tune it for your needs. You
might want to opt-in for isolated=0 to have a behavior closer to the
regular Python.


> - PyConfig.isolated is not documented.

Oops, fixed (in my current draft).


> - "Configuration files are still used with this configuration": why is
>   this?  Shouldn't they be ignored in an isolated configuration?

In short, I didn't touch the Path Configuration. You have to
explicitly set 5 fields to prevent Python to compute the Path
Configuration:

* exec_prefix
* executable
* prefix
* module_search_paths_set
* module_search_paths

https://www.python.org/dev/peps/pep-0587/#path-configuration


> - In "Comparison of Python and Isolated Configurations": what does -1
>   mean here?

Hum, the most complete documentation for the all configuration fields
currently lives at:
https://github.com/python/cpython/blob/master/Include/cpython/coreconfig.h

The design of the PEP 587 is that fields "explicitly" by the user
prevents Python to override them.

The -1 value means "unset": Python reads the value from the
environment. For example, dev_mode equals to -1 means that
PYTHONDEVMODE env var and -X dev command line variables are checked:
they set dev_mode to 1 is present, otherwise dev_mode is set to 0.
Setting dev_mode to 0 ensures that it cannot be enabled.


> Overall, this looks like a great improvement.  My only worry is that
> interactions between the various options seem complicated and
> difficult to understand.  Perhaps we will need some detailed
> documentation and examples.

"interactions between the various options" should be documentation at:
https://www.python.org/dev/peps/pep-0587/#priority-and-rules

My plan is also to move PEP 587 into the documentation, around:
http://docs.python.org/dev/c-api/init.html

The documentation can be enhanced later.

Victor