[Python-ideas] str.rreplace

[Ron Adam]

On 01/24/2014 07:36 PM, Andrew Barnert wrote:
>>>>> 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.


How about a keyword to specify which end to index from?  When used, it 
would disable negative indexing as well.  When not used the current 
behaviour with negative indexing would be the default.

     direction=0            # The default with the current
     (or not specified)     #    negative indexing allowed.

     direction=1   # From first. Negative indexing disallowed.
     direction=-1  # From last.  Negative indexing disallowed.

(A shorter key word would be nice, but I can't think of any that is as clear.)

The reason for turning off the negative indexing is it would also offer a 
way to avoid some indexing bugs as well.  (Using negative indexing with a 
reversed index is just asking for trouble I think.)

While the spelling isn't a short and concise as I would like, I could 
always wrap them in short helper functions if I wanted... ffind, rfind, 
findex, rindex.. etc.  But those wouldn't need to be added to python.

Cheers,
    Ron


> 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.