On Mon, May 06, 2019 at 07:39:39PM +0300, Serge Matveenko wrote: > With all respect, I disagree. There are ways to evolve Python such as > deprecation policies which proven to be effective. There are ways to > monitor current features adoption on PyPI to see whether it is safe to > remove deprecated things.
Monitoring adoption on PyPI tells you absolutely nothing about the millions of lines of Python code which is not on PyPI. Not every Python programmer writes open source software available to the public. They are not second-class citizens -- we have a responsibility to them too, and that's why we don't break backwards-compatibility lightly. > I'd understand if some feature is not accepted to Python if it is > kinda bad. What I refuse to accept as a user is that behavior > considered bad and ready to be improved is preserved through time just > because it is there already. Oh, you "refuse to accept" it do you? How nice. Compared to languages like C that have ISO standards, Python's attitude towards removing old features might be seen as recklessly fast. You should read this to get another perspective: https://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html > Please, get me right. I totally agree that this will bring up two ways > of performing the same thing but we can deprecate one of them, keep > track of the new way adoption and finally get Python to a better state > if it is really desired. Everything you say there is true in principle. That doesn't mean it will happen in practice. For what it's worth, I'm less concerned than Guido is about having two ways to get the same result. There's two (or three, or ...) ways to do many things in Python and "Only One Way To Do It" has never been part of the Zen of Python, it was a put-down from Perl users misrepresenting Python's philosophy. But duplication has costs: more to learn, more decisions to make, more code, more tests, more documentation. Duplicated APIs can become bloat, and bloat is not free. If a function or method doesn't bring *at least* enough benefit to outweigh the costs, then it is harmful. Code churn is not free. Forcing people to change code that works because we felt like breaking it should not be done lightly. Keeping old, suboptimal APIs versus forcing code churn is a matter of balance, and choosing the right balance is not a black and white decision to make. None of this is to say that we will never decide to deprecate or remove a feature. But it isn't clear that this proposal brings enough benefit to justify such deprecations. -- Steven _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/