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/

Reply via email to