Message320578
| 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. |
|