[Python-ideas] New list methods

[John Graham]

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?
>
> --
> Steven D'Aprano
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>

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.

-JG