On Fri, 22 Feb 2019 at 04:27, Steve Dower firstname.lastname@example.org wrote:
I've had enough ideas bouncing around in my head that I had to get them written up :)
So I'm proposing to produce an informational PEP to describe what a "good" C API looks like and act as guidance as we implement new APIs or change existing ones.
This is a rough, incomplete first draft that nonetheless I think is enough to trigger useful discussions. It's a brain dump, but I've already dumped most of this before.
They're in the text below, but I'll repeat here:
- this is NOT a brand-new API
- this is NOT exactly what we currently have implemented
- this is NOT a proposal to stop shipping half the standard library
- this IS meant to provide context for discussing both the issues with
our current API and to help drive discussions of any new API or API changes
I don't have any particular desire to own the entire doc, so if anyone wants to become a co-author I'm very open to that. However, I do have strong opinions on this topic after a number of years working with *excellent* API designs, designers and processes. If you want to propose a _totally_ different vision from this, please consider writing an alternative rather than trying to co-opt this one :)
As a broad design vision, I pretty much agree with most of what you've laid out here. The only things I'd potentially add would be:
including Python.h currently still gives you the full CPython API by default)
and the "CPython Layer", which would be something like the "Fast FFI Layer" - semantically, it would be on par with the Python layer, but it shouldn't suffer significant runtime performance overhead problems from the Python layer's dynamic dispatch capabilities. Stable ABI elements like PyDict_GetItem and PyType_FromSpec would live at this layer rather than the recompile-for-every-feature-release CPython layer.