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

[encukou (Petr Viktorin)]

@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 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?)
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.