Revisiting str.rreplace()
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,
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?
On Wed, Jul 18, 2018 at 8:20 PM Graham Gott <graham.gott.software@gmail.com> wrote:
Thoughts? Support/oppose?
+1, along with an overall rework of str methods to make them more consistent. The find, replace and split families should all gain the same tuple-as-search-string that endswith and startswith use. (Discussed in the last year, I'm too lazy to look up references...)
On Thu, Jul 19, 2018 at 7:01 AM Calvin Spealman <cspealma@redhat.com> wrote:
That could certainly be made to work, but I think it fails the discoverability test. You'd have the [:]-syntax and replace working one way, and split/rsplit, find/rfind and so on working another way. Unless you're proposing the negative index for the latter ones also?
On Wed, Jul 18, 2018 at 8:20 PM Graham Gott <graham.gott.software@gmail.com> wrote:
Thoughts? Support/oppose?
+1, along with an overall rework of str methods to make them more consistent. The find, replace and split families should all gain the same tuple-as-search-string that endswith and startswith use. (Discussed in the last year, I'm too lazy to look up references...)
On Thu, Jul 19, 2018 at 7:01 AM Calvin Spealman <cspealma@redhat.com> wrote:
That could certainly be made to work, but I think it fails the discoverability test. You'd have the [:]-syntax and replace working one way, and split/rsplit, find/rfind and so on working another way. Unless you're proposing the negative index for the latter ones also?
participants (7)
-
Calvin Spealman -
Chris Barker - NOAA Federal -
Eric Fahlgren -
Eric V. Smith -
Graham Gott -
MRAB -
Paul Moore