Pre-PEP: reverse iteration methods

[Irmen de Jong]

Raymond Hettinger wrote:
> Add a method called iter_backwards() to sequence objects that can benefit
> from it.  The above examples then simplify to::

I'm not too fond of the name "iter_backwards". I think it is too long
(with respect to the already existing "iter" built-in function).

It's just my feeling towards the name, but to me "iter_backwards" sounds
more like an action that is performed on the object it is called on
(a real method so to speak, not a factory method):
"seq.iter_backwards()" reads to me at first glance: 'iterate over the
seq in backward direction'. Not: 'return a reverse iterator object'.
('iter' reads like the verb/action 'iterate' instead of a noun).

Instead, "backwards_iter", "back_iter" or preferrably just "riter"
reads more natural to me:
"seq.back_iter()" reads to me at first glance: 'get a backwards iteration
object for seq'. ('iter' reads like the noun 'iterator', not a verb).



> No language syntax changes are needed.

Making it a method, indeed. But then there is this difference
between *forward* iteration and *backward* iteration, right?

iter(seq)    --> get a (forward) iterator for seq
seq.riter()  --> get a (backward) iterator for seq

How is this easily explained to new people? Why not keep it
orthogonal:

iter(seq)    and    riter(seq)
  ~or~
seq.iter()   and    seq.riter()

For what it's worth (probably nothing, but hey), in C++ STL
we have seq.begin() that returns a forward iterator, and
seq.rbegin() that returns a backward iterator.


> * Should tuples be included?
Don't really care. Are there any reasons why they shouldn't?

> * Should file objects be included?
Don't care. I've never had to read a file in reverse.

> * Should enumerate() be included?
I think it should.


--Irmen de Jong