Brett Cannon schrieb am 27.02.20 um 22:38:
On Thu, Feb 27, 2020 at 1:18 PM M.-A. Lemburg wrote:
[SNIP] I wouldn't really put much effort into maintaining binary compatibility anymore. For better maintenance, portability and consistency of the API is much more important.
Except I hear from people who find it burdensome to have to rebuild their wheels for every version of Python that they support, especially with a shift to an annual release cadence for Python. So while consistency and portability are definitely important, I don't think we should ignore binary compatibility either.
My experience (both personal and from what I hear) is that it's excessively more burdensome to add a new target platform (MacOS, Windows, …) than to add a new Python version to an existing build.
Once a platform is supported, adding a new Python version is just adding a new version entry to some kind of build script. With a couple of fixes every couple of years when deprecated features (Python or C-API) change and/or go away.
But to add a new platform, you often have to learn and create a completely new build setup, and sometimes even add a new build farm to your release process, which can take anything from days to weeks to months to get running nicely. Plus additional maintenance from time to time that involves remote debugging issues that you cannot reproduce on your local development platform. And that multiplies if you have non-trivial library dependencies that need building as well.
As long as PyPI is happy to load itself with lots of different wheels for each package release, and as long as there is a need (or use case) for binary wheels at all, I personally consider a stable ABI mostly a nice goodie for some, but nothing that solves the release problem for the bulk of the extension maintainers.
Stefan