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

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


Le lun. 20 mai 2019 ? 21:36, Antoine Pitrou <solipsis at> 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)) {

Does it make more sense than the current code below?

PyInitError err = Py_InitializeFromConfig(&config);
if (PyInitError_Failed(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):
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,

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

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

* exec_prefix
* executable
* prefix
* module_search_paths_set
* module_search_paths

> - 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:

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:

My plan is also to move PEP 587 into the documentation, around:

The documentation can be enhanced later.