[Python-ideas] str.rreplace

[Andrew Barnert]

From: Nick Coghlan <ncoghlan at gmail.com>
Sent: Friday, January 24, 2014 4:05 PM


>On 25 Jan 2014 04:29, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>>
>> On Jan 24, 2014, at 10:20, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> > On Fri, 24 Jan 2014 20:13:26 +0200
>> > Serhiy Storchaka <storchaka at gmail.com>
>> > wrote:
>> >> 24.01.14 19:36, Antoine Pitrou написав(ла):
>> >>> On Fri, 24 Jan 2014 19:30:00 +0200
>> >>> Serhiy Storchaka <storchaka at gmail.com>
>> >>> wrote:
>> >>>> 24.01.14 18:56, Antoine Pitrou написав(ла):
>> >>>>> On Fri, 24 Jan 2014 08:47:14 -0800 (PST)
>> >>>>> Ram Rachum <ram.rachum at gmail.com> wrote:
>> >>>>>> I propose implementing str.rreplace. (It'll be to str.replace what
>> >>>>>> str.rsplit is to str.split.)
>> >>>>>
>> >>>>> I suppose it only differs when the count parameter is supplied?
>> >>>>>
>> >>>>> I don't think it can hurt, except for the funny looks of its name.
>> >>>>> In any case, if str.rreplace is added then so should bytes.rreplace and
>> >>>>> bytearray.rreplace.
>> >>>>
>> >>>> bytearray.rremove, tuple.rindex, list.rindex, list.rremove.
>> >>>
>> >>> Not sure what those have to do with rreplace(). Overgeneralization
>> >>> doesn't help.
>> >>
>> >> If open a door for rreplace, it would be not easy to close it for rindex
>> >> and rremove.
>> >
>> > Perhaps you underestimate our collective door closing skills ;)
>>
>> While we're speculatively overgeneralizing, couldn't all of the index/find/remove/replace/etc. methods take a negative n to count from the end, making r variants unnecessary?
>Strings already provide rfind and rindex (they're just not part of the general sequence API).
>Since strings are immutable, there's also no call for an "remove".

I was responding to Serhiy's (probably facetious or devil's advocate) suggestion that we should regularize the API: add rfind and rindex to tuple (and presumably Sequence), and those plus rremove to list (and presumably MutableSequence), and so on.

My point was that if we're going to be that radical, we might as well consider removing methods instead of adding them. Some of the find-like methods already take negative indices; expanding that to all of the index-based methods, and doing the equivalent to the count-based ones, and adding a count or index to those that have neither, would mean all of the "r" variants could go away.

I think it's pretty obvious that both this suggestion and Serhiy's are not worth doing for Python—the language has had pretty much the same set of find-style methods for decades, most of them are used frequently, and people rarely go looking for any of the "missing" ones, so why change it? (And I think that was Serhiy's point as well, but I don't want to speak for him.) If people _do_ find themselves missing one particular variant, just adding that one more variant is a lot more conservative than changing everything; if not, there's no reason to add anything at all.