On 25 Jan 2014 04:29, "Andrew Barnert" email@example.com wrote:
On Jan 24, 2014, at 10:20, Antoine Pitrou firstname.lastname@example.org wrote:
On Fri, 24 Jan 2014 20:13:26 +0200 Serhiy Storchaka email@example.com wrote:
24.01.14 19:36, Antoine Pitrou написав(ла):
On Fri, 24 Jan 2014 19:30:00 +0200 Serhiy Storchaka firstname.lastname@example.org wrote:
24.01.14 18:56, Antoine Pitrou написав(ла):
On Fri, 24 Jan 2014 08:47:14 -0800 (PST) Ram Rachum email@example.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
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
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 "rremove".
rreplace (pronounced as 'ar-replace", like "ar-split" et al) is more obvious than a negative count, and seems like an almost exact parallel to rsplit.
On the other hand, I don't recall ever lamenting its absence. Call me +0 on the idea.
Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/