On 16May2019 0710, Thomas Wouters wrote:
A couple of things are documented as performing pre-initialisation (PyConfig_SetBytesString, PyConfig_SetBytesArgv). I understand why, but I feel like that might be confusing and error-prone. Would it not be better to have them fail if pre-initialisation hasn't been performed yet?
I agree. Anything other than setting up the struct for pre-initialization settings doesn't need to work here.
The dll_path field of PyConfig says "Windows only". Does that meant the struct doesn't have that field except in a Windows build? Or is it ignored, instead? If it doesn't have that field at all, what #define can be used to determine if the PyConfig struct will have it or not?
This field doesn't need to be here. It exists because it was used in getpathp.c, and Victor's internal refactoring has kept it around through all the field movement.
If we properly design initialization instead of just refactoring until it's public, I bet this field will go away.
"module_search_path_env" sounds like an awkward and somewhat misleading name for the translation of PYTHONPATH. Can we not just use, say, pythonpath_env? I expect the intended audience to know that PYTHONPATH != sys.path.
Again, this doesn't need to be its own configuration field, but because of the refactoring approach taken here it's flowed out to public API.
A "init config from environment" can load this value and put it into the "sys.path-equivalent field" in the config.
The module_search_paths field in PyConfig doesn't mention if it's setting or adding to the calculated sys.path. As a whole, the path-calculation bits are a bit under-documented. Since this is an awkward bit of CPython, it wouldn't hurt to mention what "the default path configuration" does (i.e. search for python's home starting at program_name, add fixed subdirs to it, etc.)
Again, let's design this part properly instead of exposing what we've had for years :)
Regarding Py_RunMain(): does it do the right thing when something calls PyErr_Print() with SystemExit set? (I mentioned last week that PyErr_Print() will call C's exit() in that case, which is obviously terrible for embedders.)
Can we just fix PyErr_Print() to not exit? Surely we only depend on it in one or two places (sys.excepthook?) and it's almost certainly not helping anyone else.
Regarding isolated_mode and the site module, should we make stronger guarantees about site.py's behaviour being optional?
Yes, I've been forgetting about this too. There's a lot of configuration that's split between site.py and initialization, so it's very hard to understand what will be ready when you leave out site.py. Straightening this out would help (everyone except virtualenv, probably ;) )
Cheers, Steve _______________________________________________ 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
