Unstable C API tier (PEP 689) #101101
Description
Add an Unstable C API tier as per PEP 689.
- Update CPython docs
- Update the Devguide (PEP 689: Add docs for unstable C API devguide#1060)
- Add initial unstable API from the PEP
Other candidates for inclusion are below.
These usually need discussion first. This is a checklist for having the discussion.
Please try to not hold the individual discussions in this issue.
- Dict watching API
- Functions from PEP-523 not specified in PEP-689 (
_PyEval_EvalFrameDefault& co.) -- this is a can of worms tho - FrameStack API (Add "unstable" frame stack api #91371)
-
_Py_HashDouble, see PEP 689 -- Add an unstable C-API tier #91744 (comment) - PyBytesObject.ob_shash sounds like a good candidate: see https://discuss.python.org/t/15108 (guess fields need a slightly different naming convention though. Sigh. That should have been in the PEP.)
- non-opaque access to frame structs and any other key APIs needed to implement alternate eval loops with comparable performance to the default eval loop (unless & until we can figure out stable public APIs that can deliver equivalent performance) - see Nick's reply
- C APIs that provide access to compiled code whether in AST or opcode form (the API itself may be stable, but the compiled code isn't) - see Nick's reply
-
PyLong_FromByteArray/PyUnstable_LongToBase30Digits: https://discuss.python.org/t/20045 - Anything that starts with an underscore and is documented
-
Fast access to PyLong contents[PyLong_Export]
Got any more?
I offer to move other API to the unstable tier myself, if there's a good usage example to base docs & regression tests on.