Repository navigation
Unstable C API tier (PEP 689) #101101
Description
Activity
- added a commit that references this issue
on Feb 28, 2023 @encukou #101102 caused the refleak test failure with my local machine
I submitted the related patch: #102350
See also: https://buildbot.python.org/all/#/builders/840/builds/390Hey @encukou , with the feature freeze coming up, do you have an update on the status here?
Changes described the PEP are in. Waiting for SC approval for a change before I mark it Final: python/steering-council#185
I won't be able to start all the discussions I want before beta, so the issue will stay open.
https://peps.python.org/pep-0689/ status is now Final. Can this issue be closed?
Sadly I haven't had as much time for the C API as I hoped. If you want to work on one of the items above, or move this to the C API WG, go ahead.
Reacted by AnubhavBI would like to request that the AST parsing be exposed as an Unstable C API as well. I use this to parse simple expressions that run code native to my app, rather than going through the Python interpreter which ultimately ends up back in C module code I've made using the Python C API. This is useful for common used expressions, as it gives a large speedup for the simple/common cases. The code falls back to the full interpreter when an expression includes items my parser doesn't handle.
In particular, I use
PyParser_ASTFromString
And then traverse the AST using the various enums and structs frompycore_ast.hInclude/internal/pycore_ast.handInclude/internal/pycore_asdl.hcannot easily be exposed in the public C API, even asPyUnstable. Names are not prefixed byPyprefix. Using directly structure members is more like to cause API compatibility issues if a structure changes. For example, PEP 810 (lazy imports) recently addedint is_lazy;toImportandImportFromstructures, and addedint is_lazyparameter to_PyAST_Import()and_PyAST_ImportFrom()functions.API incompatibility through struct changes is ok though, as I would expect that in an unstable API.
The original post asks:
Please try to not hold the individual discussions in this issue.
Nowadays the place for new ideas is Discourse.
That said, I like the idea in general, but I think exposing this even in the unstable API would be a huge amount of work. This is all optimized, generated code.
I use this to parse simple expressions that run code native to my app
You're essentially forking CPython; depending on a specific, tested build.
I'm thinking of closing this issue -- the world has moved on; unstable API went in a slightly different direction than I thought.
Add an Unstable C API tier as per PEP 689.
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.
_PyEval_EvalFrameDefault& co.) -- this is a can of worms tho_Py_HashDouble, see PEP 689 -- Add an unstable C-API tier #91744 (comment)PyLong_FromByteArray/PyUnstable_LongToBase30Digits: https://discuss.python.org/t/20045Fast 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 [edit 2026:] and a C API WG decision. Please discuss new ideas on Discourse.
Linked PRs