PEP 322: Reverse Iteration (second revision, please comment)

[Gonçalo Rodrigues]

On Thu, 30 Oct 2003 08:00:08 GMT, "Raymond Hettinger"
<vze4rx4y at verizon.net> wrote:

>Based on the feedback here on comp.lang.python, the pep has been
>updated:
>
>    www.python.org/peps/pep-0322.html
>
>
>The key changes are:
>
>* reversed() is being preferred to ireverse() as the best name.
>

Heh, I actually prefered ireverse. It conveys better that it produces
an iterator.

>* the sample implementation now clearly shows a check for a custom
>  reverse method and a guard against being applied to a mapping.
>
>* added sample output for enumerate.__reversed__ to show
>  how a custom reverse method would work
>
>* explained why the function is proposed as a builtin and why attachment
>   to another module or type object is not being considered further.
>
>* expanded comments on the real world use cases to show what the
>   replacement code would look like.
>
>
>Please continue to contribute your thoughts.  I'm especially interested
>in people examining their own code to verify that the new function
>adds clarity and improves performance.

I have only a couple of cases where I've needed to use reversed
iteration and in all honesty I don't think that

for index in xrange(len(lst) - 1, -1 -1):
    etc.

is all that unreadable. The use cases are so few that I can very well
live with them.

And since it cannot be put inside itertools, I'm -0 on the PEP. The
use cases are so few that I don't think it justifies being put in the
builtins or the growing of Yet Another Protocol.

Just two more notes:

- Making it a method of iter sure looks bizarre. And ugly.

- Shouldn't the implementation test for __contains__ instead of
has_key? e.g.

    if hasattr(x, "__contains__"):
        raise ValueError("mappings do not support reverse iteration")
    etc.

All my mapping-like classes overload __contains__, never has_key, but
maybe that's just me.

With my best regards,
G. Rodrigues