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.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MPOPMXJ7AZHE5MGSKCMJO4ZDJERMQNHE/ Code of Conduct: http://python.org/psf/codeofconduct/
