[Python-ideas] Revisiting str.rreplace()

[Graham Gott]

This was previously proposed here in 2014 <
https://mail.python.org/pipermail/python-ideas/2014-January/025091.html>,
but the discussion fizzled out. To me, str.rreplace() is an obvious and
necessary complement to str.replace(), just as str.rsplit() is a complement
to str.split(). It would make Python closer to the goal of the Zen of
Python: "There should be one-- and preferably only one --obvious way to do
it." To support its usefulness, this question has been asked on Stack
Overflow a number of times, (<https://stackoverflow.com/q/2556108>, <
https://stackoverflow.com/q/14496006>, <https://stackoverflow.com/q/9943504>)
with more than a trivial number of votes for the answers (>100 for the top
answer of the first two questions, and >50 for the third, not necessarily
mutually exclusive voters, but probably largely; even assuming the worst,
>100 is nothing to scoff at). While anonymous Stack Overflow votes are not
necessarily the best arbiter on what's a good idea, they at least show
interest.

My proposed behavior (though probably not the implementation details) would
be as follows (though the implementation would obviously be as a string
method, not a function, with 'self' replacing 's'):



def rreplace(s, old, new, count=-1):
    '''
    Return a copy with all occurrences of substring old replaced by new.

      count
        Maximum number of occurrences to replace.
        -1 (the default value) means replace all occurrences

    Substrings are replaced starting at the end of the string and working
to the front.
    '''
    return new.join(s.rsplit(old, count))



Addressing some (paraphrased) issues from the previous discussion, in the
form of an FAQ:

rreplace() looks weird.
>

This is maintaining consistency with the trend of 'r' prefixes for
'reverse' methods. Introducing 'reverse_' as a prefix would be
inconsistent, but worse, it would also encourage backwards incompatible
changes into existing methods. I think such a prefix naming change warrants
its own separate discussion.

There are already ways to do this. Why should we add another string method?
>

My main motivation is having one clear and efficient way to do this. I
explain this in greater detail in my introduction above.

The default of count=-1 has the same behavior as str.replace(), right?
>

Actually, it doesn't have the same behavior, as MRAB pointed out in the
previous discussion <
https://mail.python.org/pipermail/python-ideas/2014-January/025102.html>.
The default of -1 also keeps the syntax consistent with str.rsplit()'s
syntax.

If we're adding this, shouldn't we also add bytes.rreplace,
> bytearray.rreplace, bytearray.rremove, tuple.rindex, list.rindex,
> list.rremove?
>

Honestly, I don't know. I would prefer not to dilute this discussion too
much, or start making a slippery slope argument, but if it's directly
relevant, I think any thoughts are welcome.

Couldn't we just add a traverse_backwards parameter to str.replace()? In
> fact, why don't we just get rid of str.rfind() and str.rindex() entirely
> and just add new parameters to str.find() and str.index()?
>

I think Steven D'Aprano explained this well in the previous discussion
here: <
https://mail.python.org/pipermail/python-ideas/2014-January/025132.html>.
And addressing counterarguments here: <
https://mail.python.org/pipermail/python-ideas/2014-January/025135.html>.
Basically, different functions for different purposes make the purpose
clearer (no confusing/complicated parameter names and functions), and
str.rreplace() and str.replace() are usually going to be used in situations
where the traversal direction is known at edit time, so there's no need to
make the method determine the direction at runtime.



Thoughts? Support/oppose?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180718/acd0476f/attachment.html>