# PEP 803: Stable ABI for Free-Threaded Builds (packaging thread)

**URL:** https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976
**Category:** Packaging
**Tags:** pep
**Created:** [November 20, 2025, 4:53pm UTC](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976 "2025-11-20T16:53:12Z")
**Posts on this page:** 1
**Showing post:** 26

<div class="post-metadata">

### 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: [November 25, 2025, 10:14am UTC](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976/26 "2025-11-25T10:14:10Z")

</div>

> [@pf\_moore](#):
>
> As a purely technical point, the standards don’t require that the version tag has those semantics. The tag `cp311` means “works on a system that says it supports `cp311`”. It’s simply convention that Python 3.12 and later systems say that they support `cp311` as well as `cp312`.

Would it help to standardize the existing practice, which will be used for quite a while even if we change the mechanism?

> [@pf\_moore](#):
>
> Making systems that support `abi3_16` state that they also support `abi3_15` wouldn’t be a problem, it would simply mean adding a similar rule to tools (specifically the `packaging` library) that implement the current heuristics.

Plus all tools that reimplement `packaging`, right? I have feeling that this would be a much bigger problem in practice.  
How sure are you that there are “very few” dark corners that assume `packaging`’s current, non-standardized behaviour?

> [@pf\_moore](#):
>
> I wish we _had_ made the standards require that `cp311` implied `cp310` and earlier. We would have had _significantly_ smaller tag lists to check.

Looking at the [Use section](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#use) of the standard, I see that CPython 3.3 _should_ look for `py31` and `py30` – but only for `none-any`.  
(That seems to conflict with “tags are considered separately” you said [before](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds/103628/19)?)  
Reading the standard, it seems that the exact list is left to the installer tooling – that is, the list is not authoritative, but illustrates that if a tool _knows_ that `py32-none-any` is compatible with 3.3, then you can install that wheel on 3.3.  
Is that a valid reading?

If so, shouldn’t the installer apply the same principle for `py32-abi3`?  
Also, I don’t see an issue with a build tool generating `py32-abi3` when it builds on 3.3, but is _instructed_ to stay compatible with 3.2+ (setting `Py\_LIMITED\_API to 3.2).

I know that’s just one possible reading, but, it does seem to align with current practice.

> [@philthompson](#):
>
> Doesn’t the original implementation have to remain intact? Otherwise you  
> are breaking the stable ABI contract.

Alas, the stable ABI protects you from missing symbols and memory corruption, but functionality is covered by the [general backwards compatibility policy](https://peps.python.org/pep-0387/).

---

_[View the full topic](https://discuss.python.org/t/pep-803-stable-abi-for-free-threaded-builds-packaging-thread/104976)._