On 14 July 2017 at 01:35, Victor Stinner firstname.lastname@example.org wrote:
2017-07-13 15:21 GMT+02:00 Nick Coghlan email@example.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).