[Python-ideas] PEP: Hide implementation details in the C API

Nick Coghlan ncoghlan at gmail.com
Fri Jul 14 00:13:19 EDT 2017

On 14 July 2017 at 01:35, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2017-07-13 15:21 GMT+02:00 Nick Coghlan <ncoghlan at gmail.com>:
>> As far as I know, this isn't really why folks find the stable ABI hard
>> to switch to. Rather, I believe it's because switching to the stable
>> ABI means completely changing how you define classes to be closer to
>> the way you define them from Python code.
>> That's why I like the idea of defining a "portable" API that *doesn't*
>> adhere to the "no public structs" rule - if we can restore support for
>> static class declarations (which requires exposing all the static
>> method structs as well as the object header structs, although perhaps
>> with obfuscated field names to avoid any dependency on the details of
>> CPython's reference counting model), I think such an API would have
>> dramatically lower barriers to adoption than the stable ABI does.
> I am not aware of this issue. Can you give an example of missing
> feature in the stable ABI? Or maybe an example of a class definition
> in C which cannot be implemented with the stable ABI?

Pretty much all the type definitions in CPython except the ones in
https://github.com/python/cpython/blob/master/Modules/xxlimited.c will
fail on the stable ABI :)

It's not that they *can't* be ported to the stable ABI, it's that they
*haven't* been, and there isn't currently any kind of code generator
to automate the conversion process.

For the standard library, the lack of motivation comes from the fact
that we recompile for every version anyway, so there's nothing
specific to be gained from switching to compiling optional extension
modules under the stable ABI instead of the default CPython API.

For third party projects, the problem is that they need to continue
using static type declarations if they want to support Python 2.7, so
using static type declarations for both Py2 and Py3 is a more
attractive option than defining their types differently depending on
the version. As folks start dropping Python 2.7 support *then* the
stable ABI starts to become a more attractive option, as it should let
them significantly reduce the number of wheels they publish to PyPI
*without* having to maintain two different ways of defining types
(assuming we redefine the stable ABI compatibility tags to let people
specify a minimum required version that's higher than 3.2).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list