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 ncoghlan
Recipients docs@python, eric.snow, miss-islington, ncoghlan, ned.deily, vstinner, xiang.zhang
Date 2018-06-27.13:52:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1530107550.76.0.56676864532.issue33932@psf.upfronthosting.co.za>
In-reply-to
Content
https://github.com/python/cpython/pull/7967 amends the docs and adds the deprecation notices, but after taking another look at the way Victor's patch works, I'm thinking we may not need them: the *new* initialization API remains strict about the required state machine transitions, which means that calling `Py_Initialize` when only the core has been initialized will fail at the _Py_InitializeCore step (as that complains if the core has already been initialized).

Similarly, calling _Py_InitializeCore after Py_Initialize still fails, as the *only* case that becomes a no-op is specifically Py_InitializeEx, *after* the interpreter is fully initialized.

Given that, I think we can just keep Victor's compatibility fix indefinitely, and only have the new incremental initialization APIs be strict about the expected transitions through the state machine.
History
Date User Action Args
2018-06-27 13:52:30ncoghlansetrecipients: + ncoghlan, vstinner, ned.deily, docs@python, eric.snow, xiang.zhang, miss-islington
2018-06-27 13:52:30ncoghlansetmessageid: <1530107550.76.0.56676864532.issue33932@psf.upfronthosting.co.za>
2018-06-27 13:52:30ncoghlanlinkissue33932 messages
2018-06-27 13:52:30ncoghlancreate