While this is a fair point, one thing it doesn’t consider is that tooling to allow extensions to use the limited ABI is, I believe, far from ideal.
If the common build backends that allow building of binary extensions (which basically means setuptools, but this may also apply to tools like Cython) made it the default to build extensions that used only the stable ABI, how would that change things? At the moment, the simplest way to build an extension uses the full API, so that’s what everyone will do. The only people using the stable ABI will be people for whom building extensions for every new release of Python is a significant burden, which is likely to already be a very small proportion of projects.
IMO, there is a lot of benefit in the limited ABI, but only if:
- It satisfies the majority of extensions’ needs.
- Tools default to the limited ABI by default.
The first of these is what this discussion has focused on, but as far as I know, no-one is looking at what would be involved in the second. IMO, offering help to 3rd party build tools would be a better investment, if we want to support the limited ABI, than simply using it internally. If only because stdlib extensions don’t use the tools (setuptools, cython, etc) that 3rd party extensions use and so we won’t actually identify the real pain points this way.