PEP 741: Python Configuration C API (second version)

[vstinner (Victor Stinner)]

@steve.dower

Unless we find a way to completely remove preinitialization (which I still hope we can), I’d like to see it explicitly marked as optional. Possibly the best way to do that is to change it into a “set current locale” or “infer current locale” function instead, and then require it be called before the Set*Locale functions.

It’s now mostly optional, only the 2 “Locale” functions need it. If you avoid these functions, the preconfiguration is implicit and only done when Python is initialized at once by Py_InitializeFromInitConfig().

Py_PreInitializeFromInitConfig() must be called before you can call PyInitConfig_SetStrLocale(). Py_PreInitializeFromInitConfig() is responsible to configure the LC_CTYPE locale if you use PyInitConfig_CreatePython(). If you use PyInitConfig_CreateIsolated(), the LC_CTYPE locale is left unchanged: "configure_locale" option is 0 by default in the “isolated” configuration.

@steve.dower

Can we just move “coerce C locale” out of the library entirely?

I don’t think so. The current implementation cannot set temporarily the LC_CTYPE locale just during a PyInitConfig_SetStrLocale() call and then restore the locale. It would lead to mojibake and other encoding issues. This code is complicated and fragile. Just use an isolate configuration to leave LC_CTYPE unchanged.

PEP 587 added the “Python Configuration” since there are use cases to write a “custom” Python which behaves like the regular Python, but with a different default configuration.

@steve.dower

I’m still not entirely convinced by the native “Get” functions (other than PyConfig_Get).

This feature was asked by @pitrou:

@pitrou

Finally, it seems that PyConfig_Get and PyConfig_GetInt will only work if interpreter initialization was successful, since they set an exception on error? This means it’s not possible to inspect the current configuration while building it.

---

@steve.dower

The PyConfig_Get description should say that you need to be holding the GIL, and that it will read settings from the current active [sub]interpreter.

Oh sure, I will clarify these points in the doc in my next PEP update.

@steve.dower

Regarding Configuration Options, I don’t like having exhaustive lists of options like this in the PEP. People are too likely to read it as documentation and not realise that it’s not up to date (the headers we have now help, but still better to tweak the phrasing in the text).

Some PEPs now have a header saying that it’s a “historical document” and that the implementation is now the reference. I added the list since it’s uneasy to parse PyConfig and PyPreConfig members from the documentation, and the format is different (PEP 741 uses strings).

@steve.dower

Py_ExitWithInitConfig exits the entire process. We shouldn’t provide embedders this API. They can exit their own process when they’re ready.

Hum. The function made more sense in the first version of the PEP when PyInitConfig contained an “exit code”. I will remove the function, you can just use the other functions:

printf("ERROR: %s\n", PyInitConfig_GetError(config));
PyInitConfig_Free(config);
exit(1);