[Python-Dev] New Python Initialization API
Steve Dower
steve.dower at python.org
Tue Apr 9 16:51:03 EDT 2019
More information about the Python-Dev mailing list
Tue Apr 9 16:51:03 EDT 2019
- Previous message (by thread): [Python-Dev] New Python Initialization API
- Next message (by thread): [Python-Dev] New Python Initialization API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 05Apr2019 0936, Victor Stinner wrote: > For the PyMainConfig structure idea, I cannot comment at this point. I > need more time to think about it. > > > About the "path configuration" fields, maybe a first step to enhance > the API would be to add the the following function: > > PyInitError PyConfig_ComputePath(PyConfig *config, const wchar *home); > > where home can be NULL (and PyConfig.module_search_paths_env field > goes away: the function reads PYTHONPATH env var internally). Yes, I like this. Maybe pass PYTHONPATH value in as an "additional paths" parameter? Basically, this function would be the replacement for "Py_GetPath()" (which initializes paths to the defaults the first time it is called), and setting the path fields in PyConfig manually is the replacement for Py_SetPath() (or calling the various Py_Set*() functions to make the default logic infer the paths you want). Similarly, PyConfig_ComputeFromArgv() and/or PyConfig_ComputeFromEnviron() functions would also directly replace the magic we have scattered all over the place right now. It would also make it more obvious to the callers which values take precedence, and easier to see that there should be no side effects. I think it's easier to document as well. Cheers, Steve
- Previous message (by thread): [Python-Dev] New Python Initialization API
- Next message (by thread): [Python-Dev] New Python Initialization API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list