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<http://mail.python.org/mailman/listinfo/python-ideas>
-- --Guido van Rossum (on iPad)