[Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

[Steve Dower]

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