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

Guido van Rossum guido at python.org
Mon Dec 31 03:48:10 CET 2012


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


-- 
--Guido van Rossum (on iPad)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121230/4168e8d3/attachment.html>


More information about the Python-ideas mailing list