I'm pretty wary of adding methods to builtins -- I wonder how often tuples are either subclassed or duck-typed if the answer isn't "virtually never", then it's a problem to add to the API.
That being said, I do find myself wanting to change just one element of a tuple pretty frequently, and it always feels far more awkward than it should. Another possible plus would be optimization: return self[:index] + (value,) + self[index + 1:] Creates three temporary tuples (or maybe four?) in order to make one new one -- that could be far more efficient if built into the C implementation. (unless the interpreter already does some nifty optimizations) -CHB On Thu, Mar 10, 2022 at 7:35 PM Jeremiah Vivian < nohackingofkrow...@gmail.com> wrote: > > 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/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/LN3SGPGTEQV6PJPT37IVENCIACUIRZOB/ Code of Conduct: http://python.org/psf/codeofconduct/
