PEP 322: Reverse Iteration (REVISED, please comment)

[Robert Brewer]

As a relative Python newbie, I'd just like to echo those who have asked
for reverse() instead of ireverse() or inreverse(), or at least a
discussion about why that would not be a good choice. In my opinion *as
a newcomer to the language*, the name "ireverse" simply carries too much
deep magic. It might be nice to indicate the iterator nature, but to do
so with a single letter strikes me as something which would be
frustratingly obscure to newbies.

It may be that the conflict occurs with the existing list.reverse(),
which reverses in place. The programmer would have to "be aware" that
this behaves differently than the builtin reverse(). But in my opinion,
they need to be aware of the behavior regardless of the name of the
builtin. If it's a question of, on the one hand, giving experienced
Pythonistas a syntactical reminder, and on the other hand, giving Python
newbies cleaner, more understandable code, I'm going to side with the
newbs.

My 2 cents.


Robert Brewer
MIS
Amor Ministries

> -----Original Message-----
> From: Raymond Hettinger [mailto:vze4rx4y at verizon.net] 
> Sent: Wednesday, October 29, 2003 8:44 AM
> To: python-list at python.org
> Subject: Re: PEP 322: Reverse Iteration (REVISED, please comment)
> 
> 
> > 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 meant
> to simplify rather than complicate code.
> 
> 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.
> 
> 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?  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.
> 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.
> 
> 
> > In general, I'm +1 on the PEP
> 
> Thanks!  I certain it will make code more readable and reviewable.
> 
> 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.
> 
> 
> Raymond Hettinger
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
>