RetroSearch Browse

Tue Nov 4 20:12:39 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/039984.html

[Guido]
> >Ah, so it is.  Then the PEP's abstract is wrong:
> >
> >"""
> >This proposal is to add a builtin function to support reverse
> >iteration over sequences.
> >"""
> >
> >Also, the PEP should enumerate (:-) which built-in types should be
> >modified in this way, to give an impression of the enormity (or not)
> >of the task.

[Samuele]
> what is not clear to me is that the PEP is explicit about reversed() 
> refusing general iterables and in particular infinite iterators, but then 
> the combination reversed enumerate.__reversed__ would accept them or not?. 
> Will enumerate implement __reversed__ in terms of keeping the enumerate 
> argument around instead of just a iterator derived from it and reproducing 
> then the reversed behavior: limits checks and implementation strategy on 
> the original argument if/when __reversed__ is called?
> 
> so
> 
> for x in reversed(enumerate(itertools.count())):
>    pass
> 
> would throw an exception instead of not terminating, OTHERWISE with
> the strategy of consuming the iterator if x is a finite iterator but
> without __len__ then
> 
> reversed(x) would not work but
> 
> reversed(enumerate(x)) would.
> 
> Further enumerate.__iter__ does not enable re-iteration, simply it
> does not return a fresh iterator but what about
> enumerate.__reversed__ ?

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().
> 
> No other sequence object has to have a __reversed__ method.  Like its
> cousin, __iter__, some objects may be a performance boost from a custom
> iterator but none of them have to have it.

So we're back to square one: reversed(enumerate(X)) won't work, even
if reversed(X) works.

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.)

Anyway, as Raymond predicted, the discussion is being distracted by
side issues.

I personally like the idea better of having a variant of xrange() that
generates a numerical sequence backwards better.  Or perhaps we should
just get used to recognizing that [x]range(n-1, -1, -1) iterates over
range(n) backwards...

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/039984.html below:

[Python-Dev] PEP 322: Reverse Iteration