PEP 788: Address feedback from the C API WG #4521
Conversation
This is subject to change, depending on what the C API working group agrees on.
|
@AA-Turner Did I break something here, or is readthedocs acting up? Sphinx is building without warnings for me locally. |
From Line 60; the lack of packaging cross reference targets is the cause of the failure. A |
|
I restarted it and it passed this time: https://app.readthedocs.org/projects/pep-previews/builds/29079852/ |
| The interpreter will wait until a strong reference has been released | ||
| before shutting down. | ||
|
|
||
| This type is guaranteed to be pointer-sized. | ||
|
|
||
| .. c:function:: int PyInterpreterRef_Get(PyInterpreterRef *ref) | ||
| .. c:function:: PyInterpreterRef PyInterpreterRef_FromCurrent(void) |
There was a problem hiding this comment.
I prefer PyInterpreterRef_Get() and PyInterpreterWeakRef_Get() which are consistent with existing PyThreadState_Get() and PyInterpreterState_Get().
There was a problem hiding this comment.
Me too, but please bring this up on the C API WG discussion. I'm just following suggestions from Steve and Petr here.
| to a strong reference to the interpreter, and returns ``-1`` | ||
| with an exception set on failure. | ||
| On success, this function returns a strong reference to the current | ||
| interpreter, and returns ``0`` with an exception set on failure. |
There was a problem hiding this comment.
I prefer to "enforce error checking" by returning -1 on error:
PyInterpreterRef ref;
if (PyInterpreterRef_Get(&ref) < 0) {
return NULL;
}But if others prefer checking if ref is zero, I would be fine with that API as well.
…rpreterRef. Per discussion on DPO. The idea is that this is a general runtime/lifecycle API, not an operation executing on an interpreter reference.
PEP 123: Summary of changes)📚 Documentation preview 📚: https://pep-previews--4521.org.readthedocs.build/pep-0788/