[Python-Dev] Re: PEP 322: Reverse Iteration

[Guido van Rossum]

> I'm not married to the idea of __reversed__ but think it should
> probably be kept (if my intuition is off on this one, we can pull it
> out before the beta release).

Let's do it the other way around -- let's not add a complication until
we have further proof it is needed.  Remember YAGNI. :-)

> On the plus side:
> 
> * Many of the original posters either specifically requested this or
> included some variation of it in their proposals.

If any of them gave a good motivation or use case, those didn't make
it into the PEP.

> * There is a small group (including Jeremy Fincher) that consider a
> reversal protocol to be essential.

And I think that as a protocol it needs a separate PEP, because new
protocols are much more involved than new builtins.

> * It is particularly useful for xrange() because it reduces the overhead
> to zero without touching the API.  The implementation patch on SF shows
> that this can be done cleanly.  Essentially, __reverse__ forwards the
> call to __iter__ with the arguments rearranged for reverse order.

The implementation could special-case xrange() and lists and "optimize
the snot out of them" without the need for a general protocol.

> * It leaves open the possibility that someone could add __reverse__ to
> file objects, enabling them loop in reverse (helpful in reviewing log
> files for example).

That's exactly the danger.  Such a thing is much better coded as a
separate object rather than adding it to the base file object.

> * There is a small group that passionately wants reverse() to work with
> enumerate() and Alex appears to be close to figuring out how to overcome
> the implementation challenges.

Doubtful.

> * The iter/__iter__ pair neatly parallels reversed/__reversed__.

The parallel is a fallacy (see one of my previous postys about the
asymmetry).

> * It is pythonic to put hooks in for just about everything.  Sooner or
> later, someone needs the hook.  For everyone else, it's invisible.

But hook design is harder than builtin design.

> On the minus side:
> 
> * I think you got cold feet when some poster presented a wacky or
> misguided use for it.  There's no avoiding that; even Alex's dirt simple
> __copy__ protocol can be turned into an atrocity by someone so inclined.

The __copy__ protocol is limited in practice to the expectations and
promises of the copy module.  The problem with __reversed__ is that
everyone thinks it means what *they* would like to see.

> are-your-feet-feeling-warmer-now-ly yours,

No, this is one of the coldest weeks since my mvoe to Calif. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)