This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ncoghlan, steve.dower, vstinner
Date 2019-03-06.01:08:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
If Py_Main() is called after Py_Initialize(), the configuration read by Py_Main() is mostly ignored to only keep the configuration read and writen by Py_Initialize(). Only sys.argv and the internal "path configuration" are updated. Problem: in this case, "core_config" is copied into PyInterpreter.core_config anyway, creating an inconsistency.

Technically, Py_Main() could be smarter and only partially update PyInterpreterState.core_config, but... is it really worth it?

Py_Main() can get many options from the command line arguments. For example, if "-X dev" is passed on the command line, the memory allocator should be "debug". Problem: Py_Initialize() already allocated a lot of memory, and it is no longer possible to change the memory allocator.

I propose to start to emit a deprecation warning when Py_Main() is called after Py_Initialize(): calling Py_Main() alone is just fine.

See bpo-34008: "Do we support calling Py_Main() after Py_Initialize()?". I had to fix a regression in Python 3.7 to fix the application called "fontforge".

Pseudo-code of fontforge:

for file in files:
Py_Main(arg, argv)

Maybe we need to add a new "initialization" API which accepts (argc, argv)? I implemented such function in bpo-36142, but added functions are private:

* _PyPreConfig_ReadFromArgv()
* _PyCoreConfig_ReadFromArgv()

This issue has been discussed at:
Date User Action Args
2019-03-06 01:08:45vstinnersetrecipients: + vstinner, ncoghlan, steve.dower
2019-03-06 01:08:45vstinnersetmessageid: <>
2019-03-06 01:08:45vstinnerlinkissue36204 messages
2019-03-06 01:08:45vstinnercreate