Hi, Le lun. 20 mai 2019 à 21:36, Antoine Pitrou <solip...@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 _______________________________________________ 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