New-C-API-for-Python
New-C-API-for-Python copied to clipboard
markshannon
Design and discussion for the new C-API for Python
Just read the brief notes at https://github.com/markshannon/New-C-API-for-Python/blob/main/implementation.md and thought I would give you food for thought with `PyAny` as the name of the handle instead of `PyRef`. We've used this...
Type creation is a pain point in the current Limited API. (The problems are systemic -- module spec has similar issues -- but they're most visible there & a solution...
I don't know how discussions are supposed to work here, so I'm sending these as an issue: - This sounds like a Python 2→3 transition, but for the C API....
There have been a number of informative discussions over the years (especially the last few years) about the future of the C-API. It would be worth taking advantage those discussions....
It should be clear in both the design principles, and where applicable, in the design rules, that `NULL` is to be avoided as much as possible. `NULL`s are a potential...
Among past ideas about re-thinking the C-API, @zooba made a proposal about design principles that would be worth revisiting: https://mail.python.org/archives/list/[email protected]/thread/B2VDVLABM4RQ4ATEJXFZYWEGTBZPUBKW/
Portability has two dimensions, versions and implementations. E.g. If an extension is compiled to portable across versions and implementation, how does that compare to one compiled to be portable across...
A change like this IMHO needs a migration path that allows for deploying to older Python versions, for example by providing a library/header that extension authors can use to port...
https://github.com/markshannon/New-C-API-for-Python/blob/main/DesignPrinciples.md#no-invalid-states mentions "safe" values, but is a bit vague as to what is safe.
Metadata
Owner
Metadata
Design and discussion for the new C-API for Python