[Python-ideas] proposed methods: list.replace / list.indices

[MRAB]

On 2012-12-30 16:00, Ned Batchelder wrote:
> On 12/30/2012 10:05 AM, Nick Coghlan wrote:
>> On Mon, Dec 31, 2012 at 12:10 AM, Ned Batchelder <ned at nedbatchelder.com> wrote:
>>> The two sides (count/index and replace/indexes) seem about the same to me:
>>>
>>> - They are unambiguous operations.  That is, no one has objected that
>>> reasonable people might disagree about how .replace() should behave, which
>>> is a common reason not to add things to the stdlib.
>>> - They implement simple operations that are easy to explain and will find
>>> use.  In my experience, .indexes() is at least as useful as .count().
>>> - All are based on element equality semantics.
>>> - Any of them could be implemented in a few lines of Python.
>>>
>>> What is the organizing principle for the methods list (or any other built-in
>>> data structure) should have? I would hate for the main criterion to be,
>>> "these are the methods that existed in Python 2.3," for example.   Why is
>>> .count() in and .replace() out?
>> The general problem with adding new methods to types rather than
>> adding new functions+protocols is that it breaks ducktyping. We can
>> mitigate that now by adding the new methods to
>> collections.abc.Sequence, but it remains the case that relying on
>> these methods being present rather than using the functional
>> equivalent will needlessly couple your code to the underlying sequence
>> implementation (since not all sequences inherit from the ABC, some are
>> just registered).
>>
>> We also have a problem with replace() specifically that it *does*
>> already exist in the standard library, as a non-mutating operation on
>> str, bytes and bytearray. Adding it as a mutating method on sequences
>> in general would create an immediate name conflict in the bytearray
>> method namespace. That alone is a dealbreaker for that part of the
>> idea.
>
> I don't understand the conflict?  .replace() from sequence does
> precisely the same thing as .replace() from bytes if you limit the
> arguments to single-byte values.  It seems perfectly natural to me. I
> must be missing something.
>
[snip]
The difference is that for bytes and str it returns the result (they
are immutable after all), but the suggested addition would mutate the
list in-place. In order to be consistent it would have to return the
result instead.