On 11. 02. 22 19:25, Neil Schemenauer wrote:
On 2022-02-11 06:14, Petr Viktorin wrote:
Sounds reasonable, but...
The implication of endorsing code like this is that *we cannot change
private API even in patch releases*, which I don't think is documented
anywhere, and might be a bit controversial.
I think we are still allowed to change them. We should be aware of the
impact though. If an API is supposed to be private but is actually used
by a large number of 3rd party extensions, we need to consider carefully
when changing it. I don't have much sympathy for work caused for people
using clearly marked private APIs. OTOH, practicality beats purity and
we want them to be able to somehow use new versions of Python.
I'm all for "practicality beats purity" -- lots of people don't know the
complicated backcompat rules, don't read the docs, have read older
versions of docs, or don't notice things on reviews. It's bad to break
their code without reason. But IMO it's good to set clear rules and
stick to them ourselves, even if we're lenient in enforcing them.
If we don't have much sympathy for projects that use private API where
does that leave pythoncapi_compat?
Is it an exception (like Cython? SWIG? Megacorp© Codegen™?)
Or would it be hypocritical to adopt it?
Or.. hmm, maybe we should retroactively declare the workaround API as
stable in the specific CPython versions where pythoncapi_compat uses it?
(Usually, these would be the versions before it was removed.) Is that
what adopting pythoncapi_compat in the python org would mean?
_______________________________________________
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/PQY4YUPSLD67KWZHW7WAVDX7LKPVR5OJ/
Code of Conduct: http://python.org/psf/codeofconduct/
