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

[Guido van Rossum]

> Arguing that irange() is too similar to range() and xrange() is
> closer, but I'd say that irange is the *right* way to do it. [x]range
> should be relegated to backward-compatibility tools, much like the
> file xreadlines() method and the xreadlines module.

Hm.  There's a usage pattern that seems easy with [x]range() but not
so easy with irange():

    R = xrange(...)
    for x in R: ...
    for y in R: ...

IMO, being able to say "for x in R" rather than having to remember the
arguments to irange() and having to say "for x in irange(a, b, c)" is
a big and useful advantage.

IOW [x]range() returns a *sequence* which is more powerful than an
iterator, because it can be iterated more than once.

Now, the same could be accomplished with copyable iterators, but it
is still more work:

   I = irange(...)
   R1, R1 = tee(I)
   for x in R1: ...
   for x in R2: ...

> Raymond - are you dead set against an irange() function in itertools?
> Assume for now that it's a simple version without a reverse argument.
> 
> > But since (a) at least 60% of the examples are satisfied with
> > something like irevrange(), and (b) having irevrange() in itertool
> > is acceptable, my (c) conclusion is that reversed() doesn't need to
> > be a builtin either. I didn't say it had to go into itertools!
> 
> Raymond seems very protective of the concept of reversed() as a
> builtin. I'm not saying that's wrong, but I *personally* haven't seen
> enough evidence yet to be convinced either way. The i{rev}range()
> issues seem to be getting caught up in this.

Right.

> My view:
> 
> 1. I think a "plain" irange() would be useful to add into itertools.
>    In the (very) long term, it could replace [x]range, but that's less
>    of an issue to me.
> 2. A way of getting a reversed {i,x}range() has some clear use cases. 
>    This seems useful to add (although here, I'm going on evidence of
>    others' code - in my code I tend to loop over containers much more
>    often than over ranges of numbers).
> 3. A general reversed() function seems theoretically useful, but the
>    concrete use cases seem fairly thin on the ground. I'm broadly in
>    favour, because I (possibly like Raymond) have a bias for clean,
>    general solutions. But I can see that "practicality beats purity"
>    may hold here.
> 
> My proposals:
> 
> 1. Add a plain irange() to itertools.
> 2. IF the general reversed() is deemed too theoretical, add EITHER a
>    reverse argument to irange, or an irevrange to itertools. Both feel
>    to me a little iffy, but that's my generality bias again.
> 3. IF the general reversed() is accepted (builtin or not) leave the
>    irange function in its simple form.

Hm.  reversed(irange(...)) can't work, so you'd have to have both.

> > Sorry, I have to push back on that.  We still need to contain the
> > growth of the language, and that includes the set of builtins and (to
> > a lesser extent) the standard library.  You have to show that this is
> > truly important enough to add to the builtins.  Maybe you can propose
> > to take away an existing builtin to make room *first*.
> 
> xrange (in favour of itertools.irange())? :-)
> 
> [Personally, I'm still not 100% sure I see Raymond's strong reluctance
> to have reversed() in itertools, but as both are his babies, and he
> clearly has a very definite vision for both, I don't feel that I want
> to argue this one with him].

That part I understand.  reversed() is a function of a sequence
(something with __len__ and __getitem__ methods), not of an iterator,
and as such it doesn't belong in itertools.

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