[Python-ideas] str.rreplace

[Neil Girdhar]

Isn't the only reason that you don't like keyword arguments that take 
constant values a matter of efficiency?  It would be much better to make 
the compiler smarter than to make the language more verbose.  The advantage 
of keyword arguments is that you never end up with

a = x.listrip(...) if blah else x.rstrip(...)

On Tuesday, January 28, 2014 7:33:50 AM UTC-5, Steven D'Aprano wrote:
>
> On Mon, Jan 27, 2014 at 08:03:54PM -0800, Andrew Barnert wrote:
> > From: Ron Adam <ron... at gmail.com <javascript:>>
>
> > > How about a keyword to specify which end to index from?
>
> -1
>
> As a general rule, when you have a function that takes a parameter which 
> selects between two different sets of behaviour, and you normally 
> specify that parameter as a literal or constant known at edit time, then 
> the function should be split into two.
>
> E.g.:
>
> # Good API
> string.upper(), string.lower()
>
> # Bad API
> string.convert_case(to_upper=True|False)
>
> sorted() and list.sort() (for example) are a counter-example. Sometimes 
> you know which direction you want at edit-time, but there are many 
> use-cases for leaving the decision to run-time. Nearly every application 
> that sorts data lets the user decide which direction to sort.
>
> In the case of replace/rreplace, it is more like the upper vs. lower 
> situation than the sorted situation. For almost any reasonable use-case, 
> you will know at edit-time whether you want to go from the left or from 
> the right, so you'll specify the "direction" parameter as a edit-time 
> literal or constant. The same applies to find/rfind.
>
>
> > >  When used, it would 
> > > disable negative indexing as well.
>
> -1
>
> Negative indexing is a standard Python feature. There is nothing wrong 
> with negative indexing, no more than there is something wrong with 
> zero-based positive indexing.
>
> It's also irrelevant to the replace/rreplace example, since replace 
> doesn't take start/end indexes, and presumably rreplace wouldn't either.
>
>
> > > 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.
>
> And if you want to operate from the right, with negative indexing 
> allowed? But really, having a flag to decide whether to allow negative 
> indexing is silly. If you don't want negative indexes, just don't use 
> them. 
>
>
> > > (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?
> > 
> > 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.).
>
> sorted(alist, reverse=True) gives the same result as sorted(alist, 
> reverse=False) only reversed. That is not the case here:
>
>     "Hello world".replace("o", "u", 1, reverse=True)  # rreplace
>
> ought to return "Hello wurld", not "dlrow ulleH".
>
>
> > > 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?
>
> Exactly. Here, I agree strongly with Andrew. Negative indexing works 
> perfectly well with find/rfind. Slices with negative strides are weird, 
> but negative indexes are well-defined and easy to understand.
>
>
> > 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…
>
> It would be an awfully bogus argument. Negative indexes are a 
> well-defined part of Python indexing semantics. One might as well argue 
> that any scripts that rely on list slicing making a copy "deserve to be 
> broken".
>
>
> -- 
> Steven
> _______________________________________________
> Python-ideas mailing list
> Python... at python.org <javascript:>
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140203/55e324a6/attachment-0001.html>