![](https://secure.gravatar.com/avatar/be200d614c47b5a4dbb6be867080e835.jpg?s=120&d=mm&r=g)
On 3/30/2022 4:42 PM, Guido van Rossum wrote:
In the not so distant past I have proposed to introduce a new category, "Unstable APIs". These are public but are not guaranteed to be backwards compatible in feature releases (though I feel they should remain so in bugfix releases).
Agreed. This is definitely a new category, and it seems the only thing we're debating now is whether or not to add/omit the underscore.
I'm not sure whether those should have a leading underscore or not. Perhaps (like some other languages do and like maybe we've used in a few places) the name could just include the word "Unstable"?
I don't think we have "Unstable" anywhere, though we do have "Unsafe" (which is more about threading than stability, so not right for this). But I'd be okay with that as a compromise. I'd prefer to not have public-unstable APIs hidden behind the same preprocessor directive as internal APIs. That's a big switch to throw that may also activate other settings - for example, on Windows we will set the minimum Windows version in our headers if you enable internal APIs, and disable automatic linking of the Python DLL. Easy enough things to work around, but they probably need to be explicitly documented as well if we're going to document public APIs as requiring Py_BUILD_CORE (and I don't want to have to document that kind of stuff). Cheers, Steve