On 2022-03-11 12:03, wfdc via Python-ideas wrote:
I've used Python for 23+ years now. I've had occasion where I'd use this
methods maybe in the low-tens of times.
I'd call the purpose rare at best.
This comment is useless without a base rate. What's the base rate for
comparable methods that *are* part of the standard library, like index
and count?
You seem to be implicitly suggesting that we should implement all
methods that are at least as useful (or frequently needed, or whatever)
as existing methods. I have some sympathy with this view, but you seem
to be taking it to an unrealistic level. There are many things that
have been added to Python over time that are now less useful than other
things, for various reasons. We can't just draw a line and say "because
.some_method() already exists and has a usefulness score of X, anything
that is more useful must now be added" (even if it were possible to
define such a usefulness score). Moreover, to do so would only lead to
a spiral of madness, since by this logic someone else could come along
and say "well, we added .replace() to tuples and I never need that, so
there's no reason not to add this other new method most people won't
care about or use."
As far as I can see, you don't seem to be providing many substantive
arguments in favor of your proposal. All you are saying is that
sometimes it might be useful, and that there are other existing methods
that aren't super useful, so why not add this one too? To me that is
sort of like suggesting that it would be good to add a coffee machine
and a swimming pool to my car, because my car already has a cigarette
lighter and a little storage flap on the sun visor and I don't use
those, so there's no reason not to add other random stuff as well.
That isn't a very convincing argument. In deciding whether to add some
feature to a car, what's relevant is not what other features my car
already has that I'm not using, but how much it will cost (in time,
money, user confusion, etc.) to add the feature relative to how much
benefit it will bring.
Similarly, what you are not providing is any consideration of the
*costs* of adding this feature relative to the benefit. These costs
include implementation and maintenance, increased API surface area for
users to familiarize themselves with, and cluttering the type's
namespace with yet another method name (even though you seem to
acknowledge that it's already cluttered with methods that aren't very
useful). Against that we have the benefit of being able to effectively
"assign" to a tuple element, which is not zero but also not exactly a
burning need. I don't think you're going to get much traction on this
suggestion unless you at least engage with this idea of cost and
benefits of *your proposed feature* itself, rather than just focusing on
what you perceive as the low utility of things that are already part of
Python.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EKWLL4RYWP7YFW4MEO7ANRQ6CNPX25DF/
Code of Conduct: http://python.org/psf/codeofconduct/
