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).
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_COREfor internals (technically this should start with an underscore)An early revision of PEP-689 proposed
Py_USING_UNSTABLE_APIto 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).