On 29. 04. 22 16:32, Victor Stinner wrote:
> Ok, let me start with the serious business: API name.
>
> I'm not comfortable with "semi-stable". Python already has a "limited
> API" and a "stable ABI". Just by its name, it's unclear what
> "semi-stable" means.
>
> Honestly, I would be more comfortable with the name: "unstable API".
> It would be clear that the API *can* change often. People who want to
> know exactly the backward compatibility warranties can dig into the
> API documentation to learn more about it.
>
> "Unstable API" is also the name the Guido proposed for PyCode_New() last year:
>
> * Proposal: declare "unstable APIs"
> https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
> * Making code object APIs unstable
> https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
>
> Victor
Nick Coghlan argued against that term:
> "unstable" is the wrong term. We already have an unstable API tier: the
> internal API, which can change even in maintenance releases. The value of
> the new tier is that it is "semi stable": stable in maintenance releases,
> unstable in feature releases.
—
https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/
But I also like “unstable” better than “semi-stable”. Splitting the
internals into “private”/“internal” and “unstable” seems reasonable.
I think picking "semi-stable" would be giving in to the OCD nerd in all of us. :-) While perhaps technically less precise, "unstable" is the catchy name with the right association. (And yes, we should keep it stable within bugfix releases, but the name doesn't need to reflect that detail.) The "internal API" isn't an API at all (except for CPython core developers and contributors). The "unstable API" would definitely be an *API* for users outside the core.
So let's please go with "unstable".