On Tuesday 04 November 2003 08:12 pm, Guido van Rossum wrote:
> In private mail Raymond withdrew the suggestion that enumerate()
> implement __reversed__; I think Raymond won't mind if I quote him here:
>
> [Raymond]
>
> > Unfortunately, that idea didn't work out. The enumerate object does not
> > hold the original iterable; instead, it only has the result of
> > iter(iterable). Without having the iterable, I don't see a way for it
> > to call iterable.__reversed__. The essential problem that at creation
> > time, the enumerate object does know that it is going to be called by
> > reversed().
I had always assumed that enumerate.__reversed__ would attempt to call a
reversed iterator on the sequence. Since enumerate is only sensibly used on
sequences (which are guaranteed to provide a reverse iterator) it could never
fail in sensible cases (unless there's some usage of enumerate on
non-sequences that I'm missing).
> I'm not sure I even like the idea of reversed() looking for a
> __reversed__ method at all. I like the original intention best:
> reversed() is for reverse iteration over *sequences*. (See the first
> paragraph of the section "Rejected Alternatives" in the PEP.)
I think the search for the __reversed__ method is the meat of the proposal; I
can define for myself a simple two-line generator that iterates in reverse
over sequences. What I need the language to define for me is a protocol for
iterating over objects in reverse and for providing users of my own classes
with the ability to iterate over them in reverse in a standard way.
If this proposal could be satisfied by the simple definition:
def reversed(seq):
for i in xrange(len(seq)-1, -1, -1):
yield seq[i]
I wouldn't be for it. The reason I'm +1 is because I want a standard protocol
for iterating in reverse over objects.
Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4