gh-131776: Expose functions called from the interpreter loop via PyAPI_FUNC #134242
Conversation
I'm happy to defer on that, but would be fine renaming them if that seems better. But they're buried in the internal APIs and require defining |
PyUnstable functions require documentation and tests. |
| PyAPI_FUNC(PyObject *) _PyType_LookupSubclasses(PyTypeObject *); | ||
| PyAPI_FUNC(PyObject *) _PyType_InitSubclasses(PyTypeObject *); |
There was a problem hiding this comment.
It feels a little off, putting the dict out there to be modified. What do you need this for, specifically? Can we provide some specific operation (like "set a dict watcher") rather than exposing the whole dict?
There was a problem hiding this comment.
I'll drop this for now and come back and do a different PR that specifically addresses the classes. It seems like adding a whole new API for this is deserving of its own PR.
DinoV
force-pushed
the
expose_apis
branch
7 times, most recently
from
0c65264 to
42b861f
Compare
There was a problem hiding this comment.
these are all in internal headers and _Py-prefixed, I think it's fairly clear they aren't public or supported API in any meaningful sense.
it seems rather arbitrary which APIs need to be exposed and which ones do not.
since the intent is to enable alternative loop generators, perhaps it's worth adding a test that covers this use-case? e.g., a test that generates and uses an alternative interpreter, that would fail if the interpreter starts using APIs that are not exposed.
picnixz
changed the title
5 participants
These APIs are used in CPython's interpreter loop. Alternate interpreter loops can be created using the
cases_generatorscript with an additional input file that can be plugged in using PEP 523. But because these functions aren't exposed it's not possible to actually fully create these alternative interpreter loops without copying and pasting large amounts of code.