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