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

Paul Moore pf_moore at yahoo.co.uk
Tue Nov 4 16:00:40 EST 2003

Guido van Rossum <guido at python.org> writes:

>> Candidate itertools are expected to accept general iterables as inputs
>> and to work well with each other.  This function accepts only sequences
>> as inputs and cannot handle outputs from other itertools.  IOW, it
>> doesn't belong in the toolset.
> Ah, you misunderstood.  I was only arguing for irange(...,
> reverse=True) or irevrange(...); since irange() is already in
> itertools, there can clearly be no objection to adding the reverse
> option somehow.

Actually, irange() is not in itertools at the moment. Raymond could
argue that irange() isn't a suitable candidate for itertools, but given
the existence of count() and repeat(), I suspect that isn't a
particularly convincing argument.

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.

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.

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.

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

This signature intentionally left blank

More information about the Python-Dev mailing list