I would be very conservative here, since they are both builtin types, both sequences, and the reader may use the methods used as a hint about the type (a form of type inference if you will). The use case for list.replace() seems weak and we should beware of making standard interfaces too "thick" lest implementing alternative versions become too burdensome.

--Guido

On Sunday, December 30, 2012, Steven D'Aprano 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


--
--Guido van Rossum (on iPad)