STINNER Victor <vstin...@python.org> added the comment:
Hum. The code in Python 3.8 is complicated. When Py_SetPath() is called, Python
starts by computing the Python Path Configuration because of:
/* Getting the program full path calls pathconfig_global_init() */
wchar_t *program_full_path = _PyMem_RawWcsdup(Py_GetProgramFullPath());
The result is stored info _Py_path_config. Then Py_SetPath() overrides
program_full_path, prefix, exec_prefix and module_search_path of
_Py_path_config.
When Python reachs Py_Initialize(), PyConfig_Read() does not compute the Python
Path Configuration, but copies what comes from _Py_path_config.
--
I changed the code a lot of Python 3.10 to make it more deterministic and
simpler. For example, Py_SetPath() no longer computes the Python Path
Configuration.
commit ace3f9a0ce7b9fe8ae757fdd614f1e7a171f92b0
Author: Victor Stinner <vstin...@python.org>
Date: Tue Nov 10 21:10:22 2020 +0100
bpo-42260: Fix _PyConfig_Read() if compute_path_config=0 (GH-23220)
Fix _PyConfig_Read() if compute_path_config=0: use values set by
Py_SetPath(), Py_SetPythonHome() and Py_SetProgramName(). Add
compute_path_config parameter to _PyConfig_InitPathConfig().
The following functions now return NULL if called before
Py_Initialize():
* Py_GetExecPrefix()
* Py_GetPath()
* Py_GetPrefix()
* Py_GetProgramFullPath()
* Py_GetProgramName()
* Py_GetPythonHome()
These functions no longer automatically computes the Python Path
Configuration. Moreover, Py_SetPath() no longer computes
program_full_path.
This change is a little bit backward incompatible, even I would not recommend
to call Py_GetXXX() functions before Py_Initialize() in Python 3.8 or 3.9.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42902>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
