Le jeu. 5 déc. 2019 à 12:14, Thomas Wouters <tho...@python.org> a écrit : > It should, but it doesn't always :) If you forget how your data is flawed, > the 'smarter' decision can easily be wrong, instead. I do think it's a good > idea to reject ideas that would break a certain number of PyPI packages, say, > but just because it won't break them doesn't mean it won't break a > significant number of others.
What I proposed in the *rejected* PEP is to check the state at each Python release to see the progress, especially during release candidates. My intent is not to prevent incompatible changes, but more the opposite: better drive transitions to be able to make *more* incompatible changes. The PEP is nothing new, core developers are already helping a lot to provide pull requests to projects broken by incompatible changes. See for example of the PEP 570 has been handled in 3rd party code. As far as I recall, we never reverted incompatible changes. So I don't expect that suddenly, we would revert all incompatible changes because a single obscure PyPI project which was made incompatible. Maybe one good example is that the u-prefix of strings (u"unicode") removal was reverted in Python 3.3 for practicability :-) I don't think that we live in a black & white world, it's all a matter of tradeoffs ;-) Victor _______________________________________________ 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/S7MZJHF2QKJTLMJD5TGHAHQO54CR2RGM/ Code of Conduct: http://python.org/psf/codeofconduct/
