> Not every one line function needs to be a method on a built-in type.
Not every one line function needs to *not* be a method on a built-in type. See
tuple's count method for an example.
Again, if users find themselves re-implementing the same utility function over
and over again across different projects it's a good sign that such a function
should be part of the standard library.
Furthermore, other users have already pointed out that my one-liner is not the
most *efficient* way to implement it. And it also doesn't include bounds
checking.
> I like that tuples have extremely limited methods.
Why's that?
> Following the iterable protocol seems fine (also indexable).
What does this have to do with the discussion?
> If I were forced to endorse one new method for tuples, I doubt `.replace()`
> would be in my top five considerations.
List the 5 other methods you'd prefer over this one, and explain why you think
they're in higher demand and more useful.
> But if you want it, subclassing is a thing.
Doesn't solve the problem. It evades the point of why such built-in methods
exist in the first place.
Again, if users find themselves re-implementing the same utility function over
and over again across different projects it's a good sign that such a function
should be part of the standard library.
------- Original Message -------
On Friday, March 11th, 2022 at 2:28 PM, David Mertz, Ph.D.
<david.me...@gmail.com> wrote:
> -1
>
> Not every one line function needs to be a method on a built-in type.
>
> I like that tuples have extremely limited methods. Following the iterable
> protocol seems fine (also indexable).
>
> If I were forced to endorse one new method for tuples, I doubt `.replace()`
> would be in my top five considerations.
>
> But if you want it, subclassing is a thing.
>
> On Fri, Mar 11, 2022, 2:14 PM wfdc via Python-ideas <python-ideas@python.org>
> wrote:
>
>>> one Stack Overflow question, with a low number of votes
>>
>> Mind explaining why you say 159 is a "low number of votes" for a
>> StackOverflow question on Python?
>>
>> According to https://stackoverflow.com/questions/tagged/python, this puts it
>> in the top 3031 / 1908740 = 0.00159 = 0.159% of Python questions by vote
>> count.
>>
>>> And yet you haven't demonstrated that this is the case for your
>> proposal
>>
>> What kind of evidence would satisfy you? And how did previous proposals you
>> supported obtain such evidence?
>>
>> We've already had 2 other participants here attesting to frequent use of
>> this functionality.
>>
>>> it's not clear that the OP shouldn't have been using a list in
>> the first place
>>
>> This has already been explained in this thread. A list is not immutable. A
>> tuple is. Both the old and new tuples are not mutated or mutable, and we
>> want to keep it that way.
>>
>> See namedtuple's ._replace method. namedtuples are also immutable. We simply
>> want the same functionality for tuple.
>>
>> ------- Original Message -------
>>
>> On Friday, March 11th, 2022 at 4:41 AM, Paul Moore <p.f.mo...@gmail.com>
>> wrote:
>>
>>> On Fri, 11 Mar 2022 at 02:20, wfdc via Python-ideas
>>>
>>> python-ideas@python.org wrote:
>>>
>>> > 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.
>>>
>>> And yet you haven't demonstrated that this is the case for your
>>>
>>> proposal (one Stack Overflow question, with a low number of votes,
>>>
>>> where it's not clear that the OP shouldn't have been using a list in
>>>
>>> the first place, isn't particularly compelling evidence).
>>>
>>> Paul
>>>
>>> _______________________________________________
>>>
>>> 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/2A6GQZJ4G7JZMSIE6M4CU4BQMQJ62XUN/
>>>
>>> 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/YM3GUONPOVES6A7EV7BCXVBH5I6T7EQD/
>> 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/D3RUIDA5KQDRNAVG7P4WHDAPIXZR2N5P/
Code of Conduct: http://python.org/psf/codeofconduct/
