[Python-ideas] New list methods

[MRAB]

John Graham wrote:
> On Wed, May 6, 2009 at 1:03 AM, Steven D'Aprano <steve at 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?