Py_LIMITED_API=X (perhaps confusingly named), to select API that's not newer than X, and that's (very roughly) considered “good” by Python 3.2 standards
Py_BUILD_CORE for internals (technically this should start with an underscore)
An early revision of PEP-689 proposed Py_USING_UNSTABLE_API to opt-in to “unstable” API, but later it was decided that the naming is prominent enough.
More opt-in/out macros are possible. Some are suggested in #54.
There was some discussion about selecting tiers by header files instead, so instead of <Python.h> you'd #include<Python-stable.h> or <Python-unstable.h> or <Python-legacy.h> or something.
(A downside is that it would make versioning the subsets hard.)
If we do an overhaul, we might want to consolidate/reorganize/rename these (with backcompat aliases where possible, of course).
We currently have:
Py_LIMITED_API=X
(perhaps confusingly named), to select API that's not newer than X, and that's (very roughly) considered “good” by Python 3.2 standardsPy_BUILD_CORE
for internals (technically this should start with an underscore)An early revision of PEP-689 proposed
Py_USING_UNSTABLE_API
to opt-in to “unstable” API, but later it was decided that the naming is prominent enough.More opt-in/out macros are possible. Some are suggested in #54.
There was some discussion about selecting tiers by header files instead, so instead of
<Python.h>
you'd#include
<Python-stable.h>
or<Python-unstable.h>
or<Python-legacy.h>
or something. (A downside is that it would make versioning the subsets hard.)If we do an overhaul, we might want to consolidate/reorganize/rename these (with backcompat aliases where possible, of course).