> But *humans* can be confused by "replace" having a totally different API in
> different contexts.
I doubt that's the case here.
The closest equivalent to tuple's .replace method would be namedtuple's
_.replace method, which also has a different API from string's .replace method.
> I could (I believe) write "count" as an (inefficient) 1-liner, but not
> "index". I suggest it's harder than you think. (Try it!)
How much harder? Can you post your candidate?
In any case, my point still stands.
> "Not every 1-line function needs to be a built-in".
Not every 1-line function needs to *not* be a built-in.
> Well, you are 1 user. Have you evidence that there are (many) others?
See the StackOverflow link and the 2 other participants in this thread who
attested to frequent use of this functionality.
------- Original Message -------
On Friday, March 11th, 2022 at 6:30 AM, Rob Cliffe <rob.cli...@btinternet.com>
wrote:
> On 11/03/2022 02:19, wfdc wrote:
>
>>> This could cause confusion because str.replace() has a completely different
>>> API.
>>
>> We're talking about tuples here, not strings.
>
> Yes, I know, and tuples and strings are different. But *humans* can be
> confused by "replace" having a totally different API in different contexts.
> This suggests at least finding a different name for your proposed method.
>
>> 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.
>>
>>> And indeed if a replace method were added to tuples, a fair case could be
>>> made for it having the same API, viz. replace(old, new, count=-1)
>>
>> Not sure what you mean by this. Please clarify.
>
> A function that replaced tuple elements by value rather than by index would
> no doubt be useful to somebody (not that I'm proposing it). So it could use
> the same API as str.replace().
>
>>> 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.
>
> Hm, off the top of my head, I could (I believe) write "count" as an
> (inefficient) 1-liner, but not "index". I suggest it's harder than you think.
> (Try it!)
>
>> Something being simple to implement does not mean it shouldn't be built-in.
>>
>> See Python's "batteries included" philosophy.
>
> "Not every 1-line function needs to be a built-in".
>
>> 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.
>
> Well, you are 1 user. Have you evidence that there are (many) others?
> Best wishes
> Rob Cliffe
>
>> ------- Original Message -------
>> On Thursday, March 10th, 2022 at 8:38 PM, Rob Cliffe via Python-ideas
>> [<python-ideas@python.org>](mailto:python-ideas@python.org) wrote:
>>
>>> This could cause confusion because str.replace() has a completely different
>>> API.
>>> And indeed if a replace method were added to tuples, a fair case could be
>>> made for it having the same API, viz.
>>> replace(old, new, count=-1)
>>> 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.
>>> Best wishes
>>> Rob Cliffe
>>>
>>> On 10/03/2022 03:42, wfdc via Python-ideas wrote:
>>>
>>>> Add a "replace" method to tuples that returns a new tuple with the element
>>>> at a given index replaced with a given value. Example implementation:
>>>>
>>>> def replace(self, index, value):
>>>> return self[:index] + (value,) + self[index + 1:]
>>>>
>>>> See
>>>> https://stackoverflow.com/questions/11458239/how-to-change-values-in-a-tuple
>>>> for more context.
>>>>
>>>> Currently, tuples have 2 public methods: index and count. replace would be
>>>> similarly easy to implement and similarly useful.
>>>>
>>>> Furthermore, it would be a natural counterpart to nametuple's _replace
>>>> 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/TIHIG74ADMMZRKRNGR2TDZSXIMM6N7JM/
>>>> 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/THFTFWMD72FMAMZIUKGESAYUPYM42M6L/
Code of Conduct: http://python.org/psf/codeofconduct/
