PEP 322: Reverse Iteration (REVISED, please comment)

[Werner Schiendl]

Raymond Hettinger wrote:

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

Well, that of course limits the choice :-)

Let's see what's available:

inreverse --

   seems a little clumsy when used in a "for item in inreverse(seq):",
   which is probably the place where it's used most often.

   The term itself seems reasonable to me.

ireverse --

   IMHO that would suggest it belonged into itertools - which it
   according to your explanatation does NOT.

   So I'd rather 'reserve' that term if one day something there
   is needed (or end up with iireverse  ;-)

   To my non-native-english eyes it's also a bit ugly.

   And concerning simplicity, how to explain a newby the "i"
   and why it's with "reverse" but not with "enumerate".

reverse --

   According to the PEP this is not for discussion, although I'm
   with John Roth in that I think this were worth some more
   discussion.

   I do not use Python too much (yet as often as possible, but
   "job work" is done with something else.
   Still I cannot imagine why anyone should confuse a method of
   a list object (that does return None) with a builtin function
   that returns "something" to walk through an arbitrary sequence
   in reverse.

   This one fits IMHO also best to the most-direct relatives you
   mention in your post (zip, enumerate) in that it is a verb
   without any prefix.

backwards --

   I cannot remember having seem that term in any library or
   programming language, it feels strange to me.

   But it's still correct, a verb, fits the style IMHO.
   Like it more than ireverse.


So my order from most-prefered to least-prefered is:

   reverse

   inreverse

   backwards

   ireverse

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

I'd not actually claim myself a Python expert ;-)


best regards

Werner