[Python-Dev] PEP 322: Reverse Iteration
Alex Martelli
aleaxit at yahoo.com
Tue Nov 4 17:04:00 EST 2003
On Tuesday 04 November 2003 09:31 pm, Guido van Rossum wrote:
...
> option somehow. But since (a) at least 60% of the examples are
> satisfied with something like irevrange(), and (b) having irevrange()
I'm not sure it's as high as that, depending on how strictly one wants
to define "satisfied".
Say I want to (do some change, say call f() on each item) the prefix of a
list of numbers, stopping at the first zero I meet. In old Python:
for i in xrange(len(listofnum)):
value = listofnum[i]
if not value: break
listofnum[i] = f(value)
but today I'd rather code this:
for i, value in enumerate(listofnum):
if not value: break
listofnum[i] = f(value)
more concise and neat.
So, what if I want to do it to the _suffix_ , the tail, of the list, stopping
at the first zero I meet going backwards? W/o irevrange, eek:
for i in xrange(-1, -len(listofnum)-1, -1):
# usual 3-line body
or equivalently
for i in xrange(len(listofnum)-1, -1, -1):
# usual 3-line body
but irevrange would only fix the for clause itself:
for i in irevrange(len(listofnum)):
# usual 3-line body
the body remains stuck at the old-python 3-liner. reversed does better:
for i, value in reversed(enumerate(listofnum)):
if not value: break
listofnum[i] = f(value)
i.e. it lets me use the "modern" Python idiom.
If you consider thise case "satisfied" by irevrange then maybe 60% is
roughly right. But it seems to me that only reversed "satisfies" it fully.
> > 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?
I used to think it didn't, but the more at looked at code with this in mind,
the more I'm convincing myself otherwise.
> If you can prove it would be used as frequently as sum() you'd have a
> point.
No, not as frequently as sum, but then this applies to many other builtins.
> > 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...
True, but adding ONE builtin is not like adding half a dozen.
> > 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*.
I don't know if Raymond has responded to this specific request, but
I've seen other responses and I entirely concur that LOTS of existing
built-ins -- such as apply, coerce, filter, input, intern, oct, round --
could be usefully be deprecated/removed/moved elsewhere (e.g.
to a new "legacy.py" module of short one-liners for apply, filter, ... --
to math for round, oct ... -- legacy could also 'from math import'
the latter names, so that "from legacy import *" would make old
modules keep working///).
Alex
More information about the Python-Dev
mailing list