PEP 803: Stable ABI for Free-Threaded Builds

[encukou (Petr Viktorin)]

@steve.dower

From a quick look at the headers, it seems like building with Py_LIMITED_API, _Py_OPAQUE_PYOBJECT and not Py_GIL_DISABLED but labelling it abi3t should work? But is that a path we want to support? I’d rather not

I agree: yes that should work, and no I don’t think we shouldn’t support it.

@steve.dower

So we basically have a flag that checks all the conditions we want, but doesn’t actually appear again in the headers.

Right, that would be a good thing
My Py_TARGET_ABI3 & Py_TARGET_ABI3T proposal is a generalization that will do this for Py_LIMITED_API as well once GIL builds are gone.

@steve.dower

But at most, if we do have an extra knob, I’d prefer Py_LIMITED_API_T and make it override (or break on conflict with) Py_GIL_DISABLED and Py_LIMITED_API.

OK, one more iteration then:

• Py_LIMITED_API=<version>: Compile for abi3 of the given version.
• Py_TARGET_ABI3T=<version>: Compile for abi3t of the given version.

If Py_LIMITED_API=v and Py_GIL_DISABLED is set, it automatically sets Py_TARGET_ABI3T=v.
If Py_TARGET_ABI3T=v is set, it automatically sets Py_LIMITED_API=v (unless it’s already set to a higher version). And it defines _Py_OPAQUE_PYOBJECT.

This is:

• same as my earlier proposal, except Py_TARGET_ABI3 is merged with (or kept as) Py_LIMITED_API.
• same as your proposal (modulo naming), except the _T macro is versioned. This means that if/when GIL builds go away, Py_TARGET_ABI3T will be the only knob to set^[1].

Naming-wise: the packaging thread showed that Py_LIMITED_API isn’t a great name for the “target ABI” knob. With my proposal, in the long-term GIL-less possible future, it’ll only remain for backwards compatibility.

---

1. except maybe PEP 743’s Py_OMIT_LEGACY_API ↩︎