[Python-Dev] PEP 322: Reverse Iteration

Guido van Rossum guido at python.org
Tue Nov 4 15:31:02 EST 2003


> > I do think that the savings in typing from having a reverse= keyword
> > for that one use case are easily outnumbered by the extra typing for
> > the much more common use case that has reverse=True.
> > 
> > But really, I could live with either one, so Raymond can decide based
> > upon the evidence, and as I said, either way having this in itertools
> > is an argument against making reversed() a builtin.
> 
> 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.  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!

> As proposed, the reversed() function is much more general than a
> backwards xrange.  Handling any sequence is a nice plus and should not
> be tossed away.  I would like reversed() to be usable anywhere someone
> is tempted to write seq[::-1].

Sure.  But is this needed often enough to deserve adding a builtin?
If you can prove it would be used as frequently as sum() you'd have a
point.

> reversed() is a fundamental looping construct.  Tucking it away in
> another module in not in harmony with having it readily accessible for
> everyday work.  Having dotted access to the function makes its use less
> attractive.

The same can be said for several functions in itertools...

> My original proposal was to have methods attached to a few sequence
> types.  I was deluged with mail pushing toward a more universal builtin
> function and that's what is on the table now.  There have been many
> notes of support but their voices have been partially drowned by naming
> discussions and some weird ideas on places to put it.
> 
> I do not support putting it in another namespace, turning it into a
> keyword argument, or making it into yet another version of xrange.
> What's out there now is simple and direct.  Everyone, please accept it
> as is.

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

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



More information about the Python-Dev mailing list