[Python-ideas] More alternate constructors for builtin type

[Steven D'Aprano]

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