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

Guido van Rossum guido at python.org
Tue Nov 4 18:27:26 EST 2003

```> 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

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

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.