From 0527f607dedf4d955a463753018463b6314286f8 Mon Sep 17 00:00:00 2001 From: Nathan Goldbaum Date: Mon, 23 Feb 2026 13:45:29 -0700 Subject: [PATCH 1/5] PEP 803: add section for maintainer comments --- peps/pep-0803.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 69 insertions(+), 1 deletion(-) diff --git a/peps/pep-0803.rst b/peps/pep-0803.rst index 292737a1733..b415d1c8043 100644 --- a/peps/pep-0803.rst +++ b/peps/pep-0803.rst @@ -50,7 +50,6 @@ for free-threading should be prepared and defined for Python 3.15”. This PEP proposes the Stable ABI for free-threading. - Background ---------- @@ -80,6 +79,75 @@ were a part of older versions. 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 roughtly 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. + +moocore +^^^^^^^ + +The moocore project `ships seven abi3 wheels +`_. It has a much smaller +userbase than cryptography and has a smaller appetite for build complexity. 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: + + The free-threading versions are still experimental so each new + free-threading python version will need its own wheels. + + Moreover, since free-threading is still experimental and not the default, + there may be bugs that only the Python developers can fix. I would expect + most users of moocore and pymoo to use the default non-free-threaded version + of Python 3.14. + + [...] + + **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 -- are on opposite sides of the +maintainer bandwidth spectrum, but both would still really like to have a stable +ABI on the free-threaded build they can use to ship wheels and reduce their +maintenance burden. Rationale ========= From 5982204ee8ff43e9006162a667204d5a57c219b4 Mon Sep 17 00:00:00 2001 From: Nathan Goldbaum Date: Mon, 23 Feb 2026 13:57:46 -0700 Subject: [PATCH 2/5] PEP 803: add paragraph about bindings generators --- peps/pep-0803.rst | 62 ++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 56 insertions(+), 6 deletions(-) diff --git a/peps/pep-0803.rst b/peps/pep-0803.rst index b415d1c8043..38c538d337f 100644 --- a/peps/pep-0803.rst +++ b/peps/pep-0803.rst @@ -1,6 +1,7 @@ PEP: 803 Title: "abi3t": Stable ABI for Free-Threaded Builds Author: Petr Viktorin +Author: Nathan Goldbaum Discussions-To: https://discuss.python.org/t/106181 Status: Draft Type: Standards Track @@ -50,6 +51,7 @@ for free-threading should be prepared and defined for Python 3.15”. This PEP proposes the Stable ABI for free-threading. + Background ---------- @@ -79,6 +81,7 @@ were a part of older versions. 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 ------------------------------------------------------- @@ -88,6 +91,7 @@ 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 ^^^^^^^^^^^^ @@ -109,15 +113,28 @@ on discourse for a free-threaded stable ABI: 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 -`_. It has a much smaller -userbase than cryptography and has a smaller appetite for build complexity. 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: +The `moocore project ships `_ +seven ``abi3`` wheels. It has a much smaller userbase than cryptography and has +a smaller appetite for build complexity. 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: The free-threading versions are still experimental so each new free-threading python version will need its own wheels. @@ -149,6 +166,39 @@ maintainer bandwidth spectrum, but both would still really 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 is 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 ========= From 91c85bbf32aa1ae61f871eb56a77b26d8afac980 Mon Sep 17 00:00:00 2001 From: Nathan Goldbaum Date: Tue, 24 Feb 2026 08:53:58 -0700 Subject: [PATCH 3/5] PEP 803: fix author formatting --- peps/pep-0803.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/peps/pep-0803.rst b/peps/pep-0803.rst index 38c538d337f..f29df0d9050 100644 --- a/peps/pep-0803.rst +++ b/peps/pep-0803.rst @@ -1,7 +1,6 @@ PEP: 803 Title: "abi3t": Stable ABI for Free-Threaded Builds -Author: Petr Viktorin -Author: Nathan Goldbaum +Author: Petr Viktorin , Nathan Goldbaum Discussions-To: https://discuss.python.org/t/106181 Status: Draft Type: Standards Track From 76ab8946093fd0459931deecfb2497ce8739e895 Mon Sep 17 00:00:00 2001 From: Nathan Goldbaum Date: Tue, 24 Feb 2026 10:10:07 -0700 Subject: [PATCH 4/5] Apply suggestions from code review Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> --- peps/pep-0803.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/peps/pep-0803.rst b/peps/pep-0803.rst index f29df0d9050..df8f3623075 100644 --- a/peps/pep-0803.rst +++ b/peps/pep-0803.rst @@ -100,13 +100,13 @@ 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 roughtly the same amount of space on PyPI to support +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: +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) @@ -166,7 +166,7 @@ ABI on the free-threaded build they can use to ship wheels and reduce their maintenance burden. -Bindings Generators +Bindings generators ------------------- Both moocore and cryptography use bindings generators to interface with the C @@ -184,7 +184,7 @@ for an ``abi3.abi3t`` tag. Cython maintainer David Woods `says `_: - Cython is doesn't have huge problems with the number of wheels we distribute + 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 From 071251f85692773ec14d0808807196da93e45cc1 Mon Sep 17 00:00:00 2001 From: Nathan Goldbaum Date: Tue, 24 Feb 2026 10:17:31 -0700 Subject: [PATCH 5/5] PEP 803: apply comments from Manuel --- peps/pep-0803.rst | 22 +++++----------------- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git a/peps/pep-0803.rst b/peps/pep-0803.rst index df8f3623075..efe073a9fcb 100644 --- a/peps/pep-0803.rst +++ b/peps/pep-0803.rst @@ -129,23 +129,12 @@ moocore ^^^^^^^ The `moocore project ships `_ -seven ``abi3`` wheels. It has a much smaller userbase than cryptography and has -a smaller appetite for build complexity. When the topic of adding support for +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: - The free-threading versions are still experimental so each new - free-threading python version will need its own wheels. - - Moreover, since free-threading is still experimental and not the default, - there may be bugs that only the Python developers can fix. I would expect - most users of moocore and pymoo to use the default non-free-threaded version - of Python 3.14. - - [...] - - **I don't want to build for 3.14 free-threading unless you really need it.** + 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: @@ -160,10 +149,9 @@ free-threaded build, he commented: 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 -- are on opposite sides of the -maintainer bandwidth spectrum, but both would still really like to have a stable -ABI on the free-threaded build they can use to ship wheels and reduce their -maintenance burden. +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