On 11/04/2020 13:08, Ivan Pozdeev via Python-Dev wrote:
On 10.04.2020 20:20, Victor Stinner wrote:
The idea is to build a C extension only once: the built binary will be usable on multiple Python runtimes and different versions of the same runtime (stable ABI).
The idea is not new but is an extension of the `PEP 384: Defining a Stable ABI https://www.python.org/dev/peps/pep-0384/`__ implemented in CPython 3.4 with its "limited C API". The limited API is not used by default and is not widely used: PyQt is one of the only few known users.
The idea here is that the default C API becomes the limited C API and so all C extensions will benefit of advantages of a stable ABI.
In my practice with helping maintain a C extension module, it's not a problem to build the module separately for every minor release.
That's because there are only a few officially supported releases, and they aren't released frequently.
Conversely, if you are using a "limited ABI", you are "limited" (pun intended) to what it has and can't take advantage of any new features until the next major Python version -- i.e. for potentially several years!
So I don't see any "advantages of a stable ABI" atm that matter in practice while I do see _dis_advantages. So this area can perhaps be excluded from the PEP or at least given low priority. Unless, of course, you have some other, more real upcoming "advantages" in mind.
PyQt uses the stable ABI because it dramatically reduces the number of wheels that need to be created for a full release.
PyQt consists of 6 different PyPI packages. Wheels are provided for 4 different platforms. Currently Python v3.5 to v3.8 are supported.
With the stable ABI that's 24 wheels for a full release. No additional wheels are needed when Python v3.9 is supported.
Without the stable ABI it would be 96 wheels. 24 additional wheels would be needed when Python v3.9 is supported.