[Python-ideas] str.rreplace

Ron Adam ron3200 at gmail.com
Tue Jan 28 07:27:31 CET 2014



On 01/27/2014 10:03 PM, Andrew Barnert wrote:
> From: Ron Adam <ron3200 at gmail.com>
>
> Sent: Monday, January 27, 2014 7:18 PM
>
>
>> On 01/24/2014 07:36 PM, Andrew Barnert wrote:
>>>   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.)
>
> Why does it have to be -1/0/1 instead of just True/False?

Well, then it would need to be..  True/False/None

The reason it needs three modes is to save the current behaviour and not 
break anything.  Actually I'm about even on weather I like the keyword 
option or separate functions.

Also there's the case of taking a slice from the middle with a positive 
starting index and a negative ending index.  And with the exception of 
examples, nearly all string slicing, use a right and left value to get 
characters in the forward order even if they are indexed from the right.

So that gives four modes... left middle right default
With the default being what we have now.

I wonder if maybe it would be better to do these things with the string 
format method?  That is a higher level interface more suitable for adding 
options to.


> In which case we could use "reverse", the same name that's already used for similar things in other methods like list.sort (and that's implied in the current names "rfind", etc.).
>
>> 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.)
>
> But str.rfind takes negative indices today:
>
>      >>> 'abccba'.rfind('b', -5, -3)
>      1
>
> Why take away functionality that already works?

It could still work that way.. just don't specify a direction. :-)


> And of course str.find takes negative indices and that's actually used in some quick&dirty scripts:
>
>      >>> has_ext = path.find('.', -4)
>
> Of course you could make an argument that any such scripts deserve to be broken…

I'd say they are already broken in that particular case. ;-)


-Ron













More information about the Python-ideas mailing list