> We're talking about tuples here, not strings. > > Saying that a method's API differs for a completely different type, > especially when such a difference would be expected given the difference in > types, is not a valid objection. I agree with this. It was also earlier specified: > Furthermore, it would be a natural counterpart to namedtuple's _replace > method.
> > Whereas your suggestion can be written as a simple 1-liner, as you > > demonstrate. So there is no strong need for a new method for it. > The same can be said for index and count, along with numerous other methods > attached to Python's built-in types. > > Something being simple to implement does not mean it shouldn't be built-in. > > See Python's "batteries included" philosophy. > If users find themselves re-implementing the same utility function over again > and over again across different projects, it's a good sign that such a > function should be part of the standard library. Also something I agree with. What this method does is done a lot of times and it could be made a little more readable by making it into an actual method. _______________________________________________ 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/NGROTCWTWAVKO257IA2PE5WZEI33XCQT/ Code of Conduct: http://python.org/psf/codeofconduct/
