John Graham wrote:
On Wed, May 6, 2009 at 1:03 AM, Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, 6 May 2009 02:27:18 pm Terry Reedy wrote:
Carl Johnson wrote:
Would there be any interest in adding a 'reversed' kwarg to the relevant string methods, deprecating the r-methods in Python 3.2, and removing them in Python 3.3? It might make things a little simpler and unclutter the dir for strings a bit… I personally would strongly prefer a reverse keyward and would not mind de-cluttering the current set of methods too. Do you have any use-cases where you don't know whether you want forward or reverse search until runtime?
That is, where you currently write something like:
if some_var: n = astring.find(target) else: n = astring.rfind(target)
or equivalent?
I may be over architecting, but the combination of a separate function to distinguish between two different behaviors, especially something as cross cutting as doing something in reverse, seems a lot like a builder pattern. Something like the following, though I doubt the following syntax would be seen at all as pretty:
lst.reversed().find(target) #rfind lst.find(target) #left find
you can already do this with the following
reversed(lst).find(target)
but this is pretty inefficient. the purpose of a builder pattern like series of functions to 'configure' whether you want to search from the left or right would be that the 'reversed()' function in the first example wouldn't actually reverse the list, but instead reverse which side the next function that was called operated from.
I don't know if that's really that possible within the language.
Wouldn't it be like using 'find' on an enumerated iterator, returning the index where a match was found?