IMO the nogil project is likely to fail if we don’t offer a “simple” solution to distribute C extensions working on regular (GIL) Python build and nogil Pyhon build.
I do not think having to build an extra wheel will cause the nogil project to fail, even if it adds some inconvenience for package maintainers.
However, I am concerned that tying PEP 703 implementation to other issues like fixing the C API in general or requiring the stable ABI will cause the project to fail.
What I don’t get is how can a C extension maintainer support nogil and Python 3.12 with the stable ABI?
This is discussed in second paragraph of this section. They would need to build an additional wheel per platform.
What happens with a stable ABI compiled on Python 3.12 is used on Python 3.13 nogil build?
It would not load.
Honestly, the nogil change sounds big enough to motivate creating a new abi4 version
I don’t think calling these ABI changes abi4 solves any problems; it only introduces problems. The proposal adds a few functions to the stable ABI whose functionality already exists (as direct field access.). The proposed ABI changes to cp13-abi3 keep the ABI compatible with older Python versions.