diff --git a/peps/pep-0803.rst b/peps/pep-0803.rst index 292737a1733..efe073a9fcb 100644 --- a/peps/pep-0803.rst +++ b/peps/pep-0803.rst @@ -1,6 +1,6 @@ PEP: 803 Title: "abi3t": Stable ABI for Free-Threaded Builds -Author: Petr Viktorin +Author: Petr Viktorin , Nathan Goldbaum Discussions-To: https://discuss.python.org/t/106181 Status: Draft Type: Standards Track @@ -81,6 +81,111 @@ This PEP proposes additional API limitations, as required to be compatible with both GIL-enabled and free-threaded builds of CPython. +Ecosystem maintainers want decreased maintenance burden +------------------------------------------------------- + +A major advantage of the limited API and stable ABI wheels is that new +Python versions are supported on the day of release. Without stable ABI +wheels, maintainers are left with a choice between closely following CPython +releases and producing wheels during CPython beta periods or dealing with +inevitable user requests for support for new CPython versions. + + +Cryptography +^^^^^^^^^^^^ + +The cryptography project shipped 48 wheel files with their `most recent release +`_. Cryptography is +somewhat unusual in that they ship 14 wheels each for both the ``cp38`` and +``cp311`` stable ABIs to enable optimizations available in newer limited API +versions. They also ship 14 additional ``cp314t`` wheels and 6 wheels for +pypy. If there is no free-threaded stable ABI, then with Python 3.15, +cryptography will be using roughly the same amount of space on PyPI to support +two versions of the free-threaded build as *all* non-EOL versions of the +GIL-enabled build. + +Cryptography maintainer Alex Gaynor `expressed a desire +`_ +on Discourse for a free-threaded stable ABI: + + Just to state this explicitly from the PyCA maintainers perspective, as + long as we have O(1) builds, that’s ok. What we can’t/won’t do is O(n) + where we need new builds for every Python release. + +When one of the PEP authors asked him in the ``#pyca`` Libera IRC channel, he +said: + + One other thing I'll note that's *really* valuable about ``abi3`` is that it + means our old wheels keep working for new Python versions. If we have + per-Python release wheels, we have to do a bunch of work at various points + in the python release cycle (including potentially backport releases to add + new wheels, if we're not otherwise planning a release at that time). + + As maintainers, we *really* like to structure our work to avoid being "on + the clock" like that. + + +moocore +^^^^^^^ + +The `moocore project ships `_ +seven ``abi3`` wheels. When the topic of adding support for +the free-threaded build `came up on the moocore issue tracker +`_, maintainer Manuel +López-Ibáñez let the person reporting the issue know that: + + I don't want to build for 3.14 free-threading unless you really need it. + +Later, after discovering the tracking issue for supporting the limited API on the +free-threaded build, he commented: + + By the way, python/cpython#111506 is about extending the stable ABI to + support free-threaded Python. If they do that, then the builds of moocore + will work in both classical and free-threaded Python versions, without + needing to build new wheels for each Python version. + + [...] + + I will revisit this again once Python 3.15 is released. Hopefully the ABI + will be stable (or even better, free-threading will be the default). + +These two libraries -- cryptography and moocore -- both have low maintainer +bandwidth and would like to have a stable ABI on the free-threaded build they +can use to ship wheels and reduce their maintenance burden. + + +Bindings generators +------------------- + +Both moocore and cryptography use bindings generators to interface with the C +API. Cryptography uses PyO3 and CFFI while moocore uses only CFFI. Both CFFI and +PyO3 already handle all the details of abstracting over the C API to enable +different build configurations and there is no need to laboriously port +extension types to use APIs that are only available on one build or another. + +Using bindings generators will enable these projects to quickly adopt the new +stable ABI. Initial testing using the experimental ``_Py_OPAQUE_PYOBJECT`` flag +defined in CPython's ``main`` branch, indicates that PyO3, CFFI, and Cython will +all work with PEP 803 using packaging tools that have been patched to account +for an ``abi3.abi3t`` tag. + +Cython maintainer David Woods `says +`_: + + Cython doesn't have huge problems with the number of wheels we distribute + because ultimately it works fine as pure-Python. We do distribute wheels for + a few of the smaller platforms as Stable ABI wheels but that's more + "dogfooding" than because we actually need to. So I'm adding this in + anticipation that other people will find it useful rather than because I + will. + + I do remain slightly concerned that the performance trade-offs for this will + turn out to be too much for many Cython users (it's possible that the + trade-off may be different for other binding tools). That's not a huge + disaster since we're not getting rid of the regular compilation mode so + people are free to pick their own personal trade-offs. + + Rationale =========