[Python-Dev] Re: PEP 322: Reverse Iteration
Guido van Rossum
guido at python.org
Wed Nov 5 17:35:01 EST 2003
> 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.
> * The iter/__iter__ pair neatly parallels reversed/__reversed__.
The parallel is a fallacy (see one of my previous postys about the
> * 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/)
More information about the Python-Dev