On Tue, 15 Feb 2022, 2:57 am Petr Viktorin, <encu...@gmail.com> wrote:
> >> > >> Yes. > >> On older Python versions, where the public API wasn't yet available, > >> those backports use private API. If we change the private API in a > >> point release, the backport will break. > > > > Do you have an example of this? On first glance the pythoncapi_compat.h > > header only uses public APIs, other than (maybe) accessing fields of the > > thread state directly. > > That's my example. Those fields are documented as "subject to change at > any time." > > But I wouldn't be afraid to do this more generally -- if we add a public > API for something that needed private API before, freeze the old way in > previous versions. Not only add it to pythoncapi_compat, but also to > CPython CI, and maybe to the docs. > Adopting pythoncapi_compat would offer a relatively clean way to test that: if a maintenance branch change breaks pythoncapi_compat, then it's the maintenance branch that's considered broken. Cheers, Nick. >
_______________________________________________ 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/KDWC6S66DKC7FYAP7GQ43Q7UZLHPFKXR/ Code of Conduct: http://python.org/psf/codeofconduct/
