Author ncoghlan
Recipients eric.snow, grahamd, ncoghlan, pitrou, steve.dower, vstinner
Date 2019-02-17.04:57:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1550379430.23.0.597634810957.issue22213@roundup.psfhosted.org>
In-reply-to
Content
Since I haven't really written them down anywhere else, noting some items I'm aware of from the Python 3.7 internals work that haven't made their way back into the PEP 432 public API proposal yet:

* If we only had to care about the pure embedding case, this would be a lot easier. We don't though: we also care about "CPython interpreter variants" that end up calling Py_Main, and hence respect all the CPython environment variables, command line arguments, and in-process global variables. So what Victor ended up having to implement was data structs for all three of those configuration sources, and then helper functions to write them into the consolidated config structs (as well as writing them back to the in-process global variables).

* Keeping the Py_Initialize and Py_Main APIs working mean that there are several API preconfiguration functions that need a way to auto-initialize the core runtime state with sensible defaults

* the current private implementation uses the PyCoreConfig/PyMainInterpreterConfig naming scheme. Based on some of Eric's work, the PEP currently suggests PyRuntimeConfig PyMainInterpreterConfig, but I don't think any of us are especially in love with the latter name. Our inability to find a good name for it may also be a sign that it needs to be broken up into three distinct pieces (PySystemInterfaceConfig, PyCompilerConfig, PyMainModuleConfig)
History
Date User Action Args
2019-02-17 04:57:10ncoghlansetrecipients: + ncoghlan, pitrou, vstinner, grahamd, eric.snow, steve.dower
2019-02-17 04:57:10ncoghlansetmessageid: <1550379430.23.0.597634810957.issue22213@roundup.psfhosted.org>
2019-02-17 04:57:10ncoghlanlinkissue22213 messages
2019-02-17 04:57:10ncoghlancreate