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

[Nick Coghlan]

The problem is bytearray, not bytes and str.

bytearray is a builtin mutable sequence with a non-destructive replace()
method. It doesn't matter that this is almost certainly just a mistake due
to its immutable bytes heritage, the presence of that method is enough to
categorically rule out the idea of adding a destructive replace() method to
mutable sequences in general.

--
Sent from my phone, thus the relative brevity :)
On Dec 31, 2012 11:41 AM, "Steven D'Aprano" <steve at pearwood.info> wrote:

> On 31/12/12 03:58, MRAB wrote:
>
>> On 2012-12-30 16:00, Ned Batchelder wrote:
>>
>
>  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.
>>
>
> Are you seriously suggesting that because str has a replace method with
> a specific API, no other type can have a replace method unless it has
> the same API?
>
> Why must list.replace and str.replace do exactly the same thing? Lists
> and strings are not the same, and you cannot in general expect to
> substitute lists with strings, or vice versa.
>
> collections.abc.**MutableSequence would seem to me to be the right place
> for a mutator replace method.
>
>
> --
> Steven
> ______________________________**_________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121231/13d502c4/attachment.html>