bpo-22257: Private C-API for core runtime initialization (PEP 432).#1772
Conversation
|
@ericsnowcurrently, thanks for your PR! By analyzing the history of the files in this pull request, we identified @zooba, @ncoghlan and @birkenfeld to be potential reviewers. |
2caf35c to
6573e10
Compare
Python/pylifecycle.c
Outdated
There was a problem hiding this comment.
Does this need to stay? Should we have a build option to reenable it? Or a comment explaining it?
There was a problem hiding this comment.
+1 for dropping it (this is brute force debugging hackery left over from when the modified interpreter was crashing on startup)
Python/pylifecycle.c
Outdated
There was a problem hiding this comment.
What's with the change in this section?
There was a problem hiding this comment.
Not sure. Given the comment I expect it wasn't intentional.
There was a problem hiding this comment.
Almost certainly the result of a merge glitch somewhere along the line when I was still maintaining the patch out of tree.
Python/pylifecycle.c
Outdated
Python/pylifecycle.c
Outdated
There was a problem hiding this comment.
This is where we'd trigger the extra initialization step, right?
Also, why not put install_sigs into core_config?
There was a problem hiding this comment.
Both of those are sorted out in the next PR.
There was a problem hiding this comment.
But for anyone just reading these comments: "install_sigs" becomes the first field in the new config struct for the main interpreter, rather than being needed to get the core runtime going :)
6573e10 to
6deccd5
Compare
(Patch by Nick Coghlan / @ncoghlan)
Mostly this adds _PyCoreConfig/_Py_InitializeCore() and reorganizes interpreter initialization code around them. The changes align with PEP 432. The new functions are introduced here as "private" C-API while the PEP is discussed. Regardless of the status of the PEP, the changes here are an improvement to interpreter startup. As such we are making the changes now, but keeping the C-API private.