On 14. 02. 22 17:26, Ronald Oussoren wrote:
On 14 Feb 2022, at 14:07, Petr Viktorin <encu...@gmail.com
<mailto:encu...@gmail.com>> wrote:
On 14. 02. 22 13:37, Antoine Pitrou wrote:
On Mon, 14 Feb 2022 13:19:00 +0100
Petr Viktorin <encu...@gmail.com <mailto:encu...@gmail.com>> wrote:
If we don't have much sympathy for projects that use private API where
does that leave pythoncapi_compat?
If you look at pythoncapi_compat.h, it provides backports for
recently-introduced public APIs such as PyObject_CallOneArg().
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.
BTW. I’m +1 on providing this header, it makes it easier for projects to
maintain compatibility with older Python versions. That said, we should
continue to be careful and considerate when evolving the public API as
migrating a project to a newer API is still work.
Yup. I'm strongly against making pythoncapi_compat mandatory.
_______________________________________________
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/5UF322HMUGL64SXNQGYEZDHBEE3Q5D7Z/
Code of Conduct: http://python.org/psf/codeofconduct/
