# PEP 803, round two – “abi3t”: Stable ABI for Free-Threaded Builds **URL:** \ **Category:** PEPs\ **Created:** [February 16, 2026, 8:29pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181 "2026-02-16T20:29:56Z")\ **Posts on this page:** 13\ **Page:** 2
**Author:** ![stefanor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefanor/32/9984_2.png) [@stefanor](https://discuss.python.org/u/stefanor)\ **Post date:** [March 13, 2026, 8:59pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/21 "2026-03-13T20:59:26Z")
I’m concerned that there’s no discrimination in the filenames between extensions that are compatible with GIL / FT / both. That is incompatible with overlapping python library installations as Debian has been doing since Python 3. (Thanks to [PEP-3147](https://peps.python.org/pep-3147/) + [PEP-3149](https://peps.python.org/pep-3149/)). I don’t think anyone else is relying on these mechanisms much, but we are, and we expect to continue to use them for system packages, as we migrate to free-threading, too. ---
**Author:** ![dstufft](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dstufft/32/23_2.png) [@dstufft](https://discuss.python.org/u/dstufft)\ **Post date:** [March 13, 2026, 9:31pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/22 "2026-03-13T21:31:49Z")
> [@stefanor](#): > > I’m concerned that there’s no discrimination in the filenames between extensions that are compatible with GIL / FT / both. I commented on the SC [issue](https://github.com/python/steering-council/issues/333#issuecomment-4057965538), but I agree with this. Treating `.abi3.so` as the same thing as `abi3t` is breaking the contract of `abi3`, and as far as I can tell entirely unneeded since the importlib machinery supports multiple suffixes to look for, and thus the FT build can look for `.abi3t.so` and the GIL build can look for both `.abi3.so` and `.abi3t.so`. The PEP is already treating these as distinct items in wheel tags, because treating them the same would be horribly backwards incompatible across the entire ecosystem. It’s not any different for treating them the same in the filename except that maybe less (or at least different) people would be impacted. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [March 16, 2026, 1:53pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/23 "2026-03-16T13:53:09Z")
I replied on [the packaging thread](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976/84). ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [March 24, 2026, 4:48pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/24 "2026-03-24T16:48:44Z")
> [@dstufft](#): > > Treating `.abi3.so` as the same thing as `abi3t` is breaking the contract of `abi3`, and as far as I can tell entirely unneeded since the importlib machinery supports multiple suffixes to look for, and thus the FT build can look for `.abi3t.so` and the GIL build can look for both `.abi3.so` and `.abi3t.so`. I’m adding this in [PR #4862](https://github.com/python/peps/pull/4862), along with a reorganized/expanded rationale, more rejected ideas, a `nanobind` quote, and generally making things more consistently/clearly worded. ---
**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\ **Post date:** [March 29, 2026, 10:55am UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/25 "2026-03-29T10:55:51Z")
The steering council have commented on the “packaging” PEP 803 thread that this is accepted: [PEP 803: Stable ABI for Free-Threaded Builds (packaging thread) - #117 by corona10](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976/117) ---
**Author:** ![corona10](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/corona10/32/9943_2.png) [@corona10](https://discuss.python.org/u/corona10)\ **Post date:** [March 29, 2026, 1:46pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/26 "2026-03-29T13:46:26Z")
Hi @encukou and @ngoldbaum, On behalf of the Steering Council, I am happy to share that [PEP 803](https://peps.python.org/pep-0803/) has been approved. Congratulations, and thank you for your work on this PEP. We are particularly pleased to see this align well with the expectation expressed in the [PEP 779](https://peps.python.org/pep-0779/) acceptance post that [Stable ABI for free-threading should be prepared and defined for Python 3.15](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/123). This is a meaningful step toward that goal, and we are glad to see the free-threading work continue on the right path. Warm regards, Donghee on behalf of the Python Steering Council * * * Reposting this here for visibility. Sharing the same message as in my earlier post: [PEP 803: Stable ABI for Free-Threaded Builds (packaging thread) - #117 by corona10](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976/117) ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [March 30, 2026, 2:21pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/27 "2026-03-30T14:21:14Z")
Thank you for your input, everyone here! I’ve marked the PEP as accepted, filed an [implementation issue](https://github.com/python/cpython/issues/146636) and will add the bits, tests & docs for the upcoming alpha release. I’m aware that the PEP doesn’t make everyone happy, but, it’s the step we’re making in 3.15. As a reminder, features can be changed during the beta period, so if you find that something’s off in practice, there’s still time to change it. ---
**Author:** ![wjakob](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/wjakob/32/7265_2.png) [@wjakob](https://discuss.python.org/u/wjakob)\ **Post date:** [March 30, 2026, 10:23pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/28 "2026-03-30T22:23:47Z")
Just a quick note that it would be great if stable ABI element access to `PyVarObject`could still be added. This would be needed for nanobind to support abi3t. nanobind is used as the binding layer of several flagship machine learning projects. Some of them have free-threading packages that stand to benefit: LLVM’s MLIR and XLA projects, Google’s JAX framework, Apple’s MLX framework. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [March 31, 2026, 3:42pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/29 "2026-03-31T15:42:16Z")
I know, but it’s looking like a 3.16 feature at this point. I’d like to do it right, and while I probably could do it in the month we have until feature freeze, there’s too little time for volunteer reviews (and also for explaining the change – PEP 697 was already quite dense). The workaround is shipping extra builds/wheels for `cp315-cp315t`, for one more year. I’ll make sure the docs point that out. ---
**Author:** ![kumaraditya303](https://avatars.discourse-cdn.com/v4/letter/k/a88e4f/32.png) [@kumaraditya303](https://discuss.python.org/u/kumaraditya303)\ **Post date:** [April 2, 2026, 6:57pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/30 "2026-04-02T18:57:30Z")
> [@wjakob](#): > > Just a quick note that it would be great if stable ABI element access to `PyVarObject`could still be added. This would be needed for nanobind to support abi3t. I think nanobind can switch its object layout of `nb_func` which currently uses `PyVarObject` to use regular `PyObject` header. If this is done then it doesn’t need to wait for 3.16 to add `PyVarObject` stable ABI support. I have created [use regular object layout for nb\_func by kumaraditya303 · Pull Request #1324 · wjakob/nanobind · GitHub](https://github.com/wjakob/nanobind/pull/1324) to implement this and it seems to work. ---
**Author:** ![wjakob](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/wjakob/32/7265_2.png) [@wjakob](https://discuss.python.org/u/wjakob)\ **Post date:** [April 12, 2026, 3:07pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/31 "2026-04-12T15:07:19Z")
@kumaraditya303 A good part of nanobind’s speedups (over pybind11) stem from a reduction of pointer chasing. It co-locates binding data structures with the underlying Python objects. The fix you proposed splits the function objects from its internals and is therefore not an acceptable solution to me. ---
**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\ **Post date:** [April 12, 2026, 6:28pm UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/32 "2026-04-12T18:28:43Z")
> [@wjakob](#): > > A good part of nanobind’s speedups (over pybind11) stem from a reduction of pointer chasing. For what it’s worth, that’s also my main concern with this PEP - that it turns “look-up the object struct” into a pointer-chase involving at least two type objects. I do get that there probably isn’t another good way of solving the problem while the GIL and free-threading builds co-exist. But long-term I’m not-very-secretly holding out hope for a free-threading-only API with non-opaque objects ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [April 13, 2026, 10:36am UTC](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181/33 "2026-04-13T10:36:42Z")
> [@da-woods](#): > > But long-term I’m not-very-secretly holding out hope for a free-threading-only API with non-opaque objects It exists - just don’t opt into the stable ABI. That means making more builds, but it’s a pretty clear tradeoff, and builds are almost certainly automated these days. It would also help if you could help us calm down people who get angry when the non-opaque objects change and “break” them,\[1\] as that will help avoid the message we keep hearing that we need to provide 100% speed, 100% flexibility and 100% stability all at once. It’s taken years, but we’ve landed on a stable option and a fast/flexible option, but you can’t have them both at once. * * * 1. You can get angry at us if we change them at the wrong time, but between releases is not the wrong time. [Previous page](https://discuss.python.org/t/pep-803-round-two-abi3t-stable-abi-for-free-threaded-builds/106181.md?page=1)