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 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[snip]
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.
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@python.org
http://mail.python.org/mailman/listinfo/python-ideas