PEP 322: Reverse Iteration (REVISED, please comment)

Alex Martelli aleax at aleax.it
Wed Oct 29 15:41:08 EST 2003


Raymond Hettinger wrote:

>> The static method approach would clearly document that the
>> result is an iterator (which none of the other names proposed
>> really does IMHO)
> 
> Better name are welcome!
> 
> Moving it somewhere else is not open.  It is proposed as a builtin for a
> reason -- it is a core looping tool like zip() or enumerate() and it is

I don't think it has anywhere like the frequency of use of either.

> Static methods, class methods, and weird descriptors be darned, this is
> not an exercise in how weirdly it can be implemented just to avoid
> having a builtin.

I just don't think it's worth making a built-in.


> Would everything be somehow better if Alex's wonderful sum() had
> been implemented as a int.sum() classmethod or was tucked way in
> another module?

int.sum would be a disaster either way: if it was forced to return
an int it would reduce use cases substantially; if it wasn't it
would be just weird.

math.sum would be arguably equivalent to sum as a built-in -- a
tad less immediately accessible, but perhaps superior in that it
immediately suggests it's about numbers only, so we'd avoid the
icky performance trap you now get with sum(manylists, []) {which
makes sum only 2/3 wonderful at best -- fine with numbers ONLY}.

> Of course not!  Likewise, would zip() or enumerate()
> be successful solutions to lock-step iteration and the loop-counter
> problems if they were iter.zip() and iter.enumerate()?  No, of course not.

zip is currently an INFERIOR solution for lock-step iteration: your
itertools.izip is much better for that.  Unfortunately zip IS
constrained to return a list BUT that fact is not reflected in it
being a classmethod list.zipped (we didn't have classmethods when
zip was introduced, so that wasn't an option).  If it had been made
one, then by now we might have a built-in version of izip, sigh.

Your enumerate is excellent, and just as frequently used as izip.
I prefer it as a builtin -- though I wouldn't be heartbroken if it
had been in itertools, but it's better in the builtins _because_
it's so frequently used.

Unfortunately we have too many and inappropriate builtins and they're
not going to go away until 3.0 (years away).  This raises the bar for
other not-obviously-indispensable built-ins more than it would be
sensible to do in a hypothetical "greenfield design".


> Let's put an end to this silliness right now.  The idea is offered as a
> builtin or not at all; otherwise, the existing [::-1] starts to look
> better.

You're clearly overwrought, so I won't "see" that "silliness" and get
offended by it.  If the choice was only to have the reverser (by
whatever name) as a built-in or not at all, I'd be -0 on the reverser --
slightly against, though not enough to bother opposing it.  If it
could be sited somewhere appropriate (ok, not as iter.reversed if
that's technically unfeasible -- i did say "appropriate":-) I'd be +1.


> The challenge with a PEP this simple is that experts feel this
> overpowering urge to apply all their know-how and transform
> in to something other than a clean, fast, simple solution.

The crux of our disagreement, namecalling apart, might be highlighted
by your assertion in another short and emotional post:

> This is supposed to be something you can teach in the first half-hour

I can't imagine "teaching this in the first half-hour" of any Python
course I teach.  There are FAR too many other functions, including
non-builtin ones such as sys.exit, and some in itertools too, that are
more important than this, in my own assessment.

So we disagree about frequence of usage, and consequently "warrantedness" 
as a built-in -- big deal.  I honestly don't understand how this purely
technical disagreement can explain these intense emotions.

_I_ am supposed to be the Latin, Mediterranean, hot-blooded enthusiast,
after all, and on average I think I cover the role adequately.

Oh well, with the incredible amount of good things you've done for Python
development, I guess you're surely entitled to blow your top occasionally,
if that's your preference.  Also, presumably, to get your pet built-in
into the language, as you've slipped it past Guido.  As for name, I
therefore second the neatest suggestion I've seen: since it IS a reversed
iter, and we can't directly call it that, then:

    reti

Hey, it IS short, so if it's gonna be so heavily used, good thing, no?-)


Alex





More information about the Python-list mailing list