Hi,
Last months, I was busy to fill https://pythoncapi.readthedocs.io/ website with random notes. Many discussions occurred on this list and python-dev, but I was only able to make the most simple and least controversal changes in Python upstream. I didn't write a PEP because CPython had a governance crisis. Since a new Steering Committee has been elected, it's time to see how concrete PEP can be written.
IMHO we need to split the giant "C API" problem into multiple PEPs. I propose 4 PEPs:
PEP A: Ecosystem of C extensions in 2019 PEP B: Define good and bad C APIs PEP C: Plan to enhance the existing C API PEP D: Completely new C API
There is also an ongoing discussion about embedded Python and Python initialization API, but I'm scared by this topic so I don't even propose to write a new PEP which would supersed PEP 432 :-) https://bugs.python.org/issue22213
== PEP A: Ecosystem of C extensions in 2019 ==
Discuss cffi, Cython, PyQt usage of the stable ABI, CPython C API, etc. The goal is not to solve any problem, mostly to list existing options.
It sounds like an unsual PEP, but I think that a PEP is needed since the same discussions happened multiple times.
This PEP can describe what are the kind of "C extensions" and maybe suggest which tools are the best depending on the kind. cffi doesn't cover all cases, the C API isn't always the right answer, etc.
== PEP B: Define good and bad C APIs ==
https://pythoncapi.readthedocs.io/bad_api.html can be used as a starting point. It should be an informal PEP which evolves as PEP 7 and PEP 8 are evolving.
== PEP C: Plan to enhance the existing C API ==
This one sounds like the most controversial PEP :-) I see different things:
- Plan to deprecate and remove bad APIs
- Plan to help C extensions maintainers to move away from these bad APIs
- Plan to test the stability of the API
- Plan to test the stability of the ABI
The even more controversial idea: provide multiple Python runtimes for CPython, not only one: https://pythoncapi.readthedocs.io/runtimes.html
== PEP D: Completely new C API ==
Well, that's the obvious alternative to PEP C.
Armin Rigo's PyHandle idea may be a good start? https://pythoncapi.readthedocs.io/pyhandle.html
Victor
Night gathers, and now my watch begins. It shall not end until my death.