On Sat, 23 Feb 2019 at 03:19, Victor Stinner <vstinner@redhat.com> wrote:
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.
For tooling recommendations, https://packaging.python.org/guides/packaging-binary-extensions/ would be a better place to contribute updates than a snapshot-in-time PEP.
An informational PEP could potentially cover options that we've currently omitted from the packaging guide as being overly niche or experimental, though.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia