In PEP 384 [1] it says:
"This PEP proposes to define a stable set of API functions whichare guaranteed to be available for the lifetime of Python 3, and which will also remain binary-compatible across versions."
Thus there are two parts that the PEP ties together closely: the limited API (AKA Py_LIMITED_API) and the stable ABI. For the most part, the API stability goal was driven by ABI stability.
Lately the binary compatibility part has seemed less important (as implied by sprint/list discussions), while the limited API has begun to stand on its own conceptually. On top of that, the limited API has started to take on a second, distinct-but-similar role: "an approximation of the minimal future API" or "the basic API that most extensions should stick to". In that case strict compatibility is desirable but not required (like it is with the stable ABI) or quite so important.
Do we want a stand-alone public API that is focused on a minimal set and extra resilient to future changes (but with less strict compatibility guarantees)? If so then we should be deliberate about it:
- introduce a different macro (Py_BASIC_API? Py_MINIMAL_API?)
- assess which parts of the limited API to keep in this new API (and what to add from the full API)
- decide if there are any future-looking gaps we could fill (e.g. with macros)
- document the inclusions explicitly
- make (relative) compatibility guarantees clear
This will provide what folks are after (mostly) without incurring the maintenance cost of binary compatibility. It seems like there's a lot of overlap here with PEP 652, though I'm suggesting a distinct API.
Regardless, I think Py_LIMITED_API should preserve its strong association with the stable ABI.
Finally, is such a "minimal" API worth it? Is the current full "public" API sufficient (and projects like HPy can be the less-constrained, future-oriented adaptations)? Would a minimal API mean we'd be more free to make breaking changes in the rest of the public API?
-eric