See https://sourcegraph.com/search?q=context:global+lang:python+%5C%5B%5Cs*:%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%5D%5Cs*%5C%2B%5Cs*%5C%28.*%5C%2C%5C%29%5Cs*%5C%2B%5Cs*%5B%5Cw%5C.%5D%2B%5C%5B%5Cs*%28i%7Cj%7Ck%7Cind%7Cindex%29%5Cs*%5C%2B%5Cs*1%5Cs*:%5Cs*%5C%5D&patternType=regexp
https://sourcegraph.com/search?q=context:global+lang:python+%3D%5Cs*list%5C%28%5B%5Cw%5C.%5D%2B%5C%29%5Cs*%5Cw%2B%5C%5B%5Cw%2B%5C%5D%5Cs*%3D%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%5B%5Cw%5C.%5D%2B%5Cs*%3D%5Cs*tuple%5C%28%5Cw%2B%5C%29&patternType=regexp ------- Original Message ------- On Monday, March 14th, 2022 at 8:39 AM, Brendan Barnwell <brenb...@brenbarn.net> wrote: > 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/ _______________________________________________ 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/V73PRCK54RF2OI4PFBCRK7URHHH376ZQ/ Code of Conduct: http://python.org/psf/codeofconduct/
