On 26/09/2021 05:21, Steven D'Aprano wrote: [snip]
As for the C-API... Python is 30 years old. Has it ever had a stable C-API before now? Hasn't it *always* been the case that C packages have targetted a single version and need to be rebuilt from source on every release?
No.
These are not rhetorical questions, I genuinely do not know. I *think* that there was an attempt to make a stable C API back in 3.2 days: https://www.python.org/dev/peps/pep-0384/ but I don't know what difference it has made to extension writers in practice. From your description, it sounds like perhaps not as big a difference as we would have liked. Maybe extension writers are not using the stable C API? Is that even possible? Please excuse my ignorance.
PyQt has used the stable ABI for many years. The main reason for using it is to reduce the number of wheels. The PyQt ecosystem currently contains 15 PyPI projects across 4 platforms supporting 5 Python versions (including v3.10). Without the stable ABI a new release would require 300 wheels. With the stable ABI it is a more manageable 60 wheels.
However the stable ABI is still a second class citizen as it is still not possible (AFAIK) to specify a wheel name that doesn't need to explicitly include each supported Python version (rather than a minimum stable ABI version). In other words it doesn't solve the OP's concern about unmaintained older packages being able to be installed in newer versions of Python (even though those packages had been explicitly designed to do so).
Phil _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RPDUNMG6RS4FBG6GODZDZ4DCB252N4VP/ Code of Conduct: http://python.org/psf/codeofconduct/
