`--disable-gil` builds are not compatible with the limited API

[colesbury]

Bug report

After #110764, --disable-gil builds of CPython 3.13 are (temporarily) not be compatible with the limited API or the stable ABI due to modifications to the PyObject header. For context, this was noted in the "Backwards Compatibility" section of PEP 703.

Based on feedback on the related discuss post and discussions with Gregory Smith, Guido, Petr, and Victor at the core dev sprint, I believe we can make changes to the stable ABI so that extension author can target a single stable ABI that supports CPython 3.7+ and both the default build and the --disable-gil builds of CPython 3.13+.

These changes will require a PEP. This issue is intended just to keep track of the known problem.

The rough idea is:

1. make a number of macro/inline functions (e.g., Py_SIZE, Py_TYPE, Py_SET_REFCNT, Py_REFCNT) "real" function calls in the stable ABI for CPython 3.13+
2. When targeting CPython <= 3.12, use dynamic symbol lookup (GetProcAddress on Windows) or weak symbols (on Linux/macOS) to determine at runtime if the active CPython version provides the desired functions. Otherwise, fall back to old definitions of the above functions for CPython <= 3.12.

Linked PRs

• gh-111506: Implement Py_SET_REFCNT() as opaque function in limited C API #111508
• gh-111506: Implement Py_REFCNT() as opaque function call #112747
• gh-111506: Rename _Py_SetRefcnt() to Py_SET_REFCNT() #112794
• gh-111506: Implement Py_SET_REFCNT() as inline function #112798
• gh-111506: Error if the limited API is used in free-threaded build #117762

[corona10]

cc @vstinner

[vstinner]

Before creating a whole new ABI, I would like first to avoid __asm__(...); in Include/*.h, in the limited C API. Assembly code is not portable and can cause compilation issues.

A first step for that is to implement Py_SET_REFCNT() as a function call: PR #111508.

[encukou]

These changes will require a PEP.

Please, could we have the PEP first, then do the changes?