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

[encukou (Petr Viktorin)]

Thanks for the review!
The sections I recommended lack some context – but it’s probably better if you get the context by asking here than wade through API/ABI details :‍)

@pf_moore

In “compatibility overview” you say “Wheels with these tags cannot be built; see table below”. Technically, they can be “built”, simply by building a wheel with any old tags, and then renaming it . It’s a subtle distinction, but the important point is that the tags are what the wheel provider asserts are supported, and the standard should be explaining what a given assertion means. So, for example, I’d see cp314-abi3t as meaning:

Works on any free-threaded build from Python 3.14 onwards. However, the 3.14 and 3.15 ABIs are incompatible, so this tag will never be valid in a published wheel.

Same for cp314-abi3.abi3t. It’s not about “whether you can build it”, it’s about “whether it’s ever valid to claim that it’s true”.

In “cannot be built; see table below“, the “cannot be built” is a simplification. The table below says:

reserved: A mechanism to build a matching extension is not proposed in this PEP, but may be added in the future. Installers should be prepared to handle the tag.

In another place, the PEP says:

Note that this PEP does not provide a way to target Stable ABI for Free-threaded Python 3.14 and below (cp314-abi3t). This may change an the future, or with experimental build tools, so installers should be prepared for such extensions.

See also the Rejected idea for 3.14 shim.

It is actually technically possible to build a working cp314-abi3.abi3t wheel.
There’s nothing stopping PyO3 or Cython from allowing this (technically – on the packaging side they’d need a new standard, bespoke support from some build tool, or indeed just telling users to rename the wheel). But it’s out of scope of this PEP, and it’ll probably stay out of scope for CPython core.

@pf_moore

For a free threading build, should it respond…

It should respond:

  cp315-cp315t-win_amd64
  cp315-abi3t-win_amd64
  cp315-none-win_amd64
  cp314-abi3t-win_amd64
  cp313-abi3t-win_amd64
  cp312-abi3t-win_amd64
  cp311-abi3t-win_amd64
  cp310-abi3t-win_amd64
  ...

The PEP says, They should allow abi3t-tagged wheels for free-threaded builds wherever they currently allow abi3-tagged ones for (otherwise equal) non-free-threaded builds. I agree the wording doesn’t match the separation of concerns in the implementations, but yeah, the intent is that you do everything (i.e., generate the list) as for a GIL-ful build, but replace abi3 by abi3t.

So, yes, installers should be prepared for a cp37-abi3.abi3t-win_amd64 wheel. The PEP says this:

Note that this PEP does not provide a way to target Stable ABI for Free-threaded Python 3.14 and below (cp314-abi3t). This may change an the future, or with experimental build tools, so installers should be prepared for such extensions.

I’m not judging how practical that would be for 3.7, but for 3.14 this was an explicit request. If we want to exclude some old versions we can, but that would be drawing an arbitrary line.
(It’s also worth noting that neither CPython nor installers should be on the hook for ensuring that a cp37-abi3.abi3t-win_amd64 wheel actually works – that’d be on whomever/whatever built/tagged it.)

@pf_moore

When does this PEP need to be approved by, in order to fit with the Python 3.15 release schedule? Is beta 1 (“no new features”) a hard deadline here?

Beta 1 is the hard deadline for the CPython implementation. For this PEP, there’s no heavy lifting left to do in CPython, so it’s more of a deadline for requesting/implementing CPython functionality changes. And of course the SC may choose to pronounce without your review.
Once accepted & implemented, details can change (or the feature can get thrown out) up to rc1 (in July).