Comment on PEP-0322: Reverse Iteration Methods

[David Abrahams]

Alex Martelli <aleax at aleax.it> writes:

> Raymond Hettinger wrote:
>
>>> And I still think you don't need it often enough to put it in the
>>> builtin namespace, so the function should go in the itertools module.
>> 
>> If you have a magic method, __riter__, then the corresponding
>> function needs to be a builtin.  They go hand in hand.  The
>> core parts of the language need to be usable without having
>> to know about itertools.
>
> I have already seen module copy presented as a counter-example to
> your assertion, and I'd like to add module pickle as a second, and
> I hope decisive, counter-example.  It is, to put it simply, utterly
> false that functions corresponding to magic methods "need to be
> builtins": it's *perfectly* all right for such functions to live
> in standard library modules.  Oh, and let's not forget module sets:
> the __as_immutable__ and __as_temporarily_immutable__ magic methods,
> that are used when making a set of sets, or checking for a set's
> membership in another set, can be seen as yet another example (and
> in this case there is no wiggling out of it by claiming that the
> magicmethod/NON-builtin correspondence is a historical/legacy thing,
> as the BDFL approved module sets.py, with just this usage, so very
> recently).
>
> I second the motion that function riter, with check for __riter__
> and all, should live in module itertools.  Reverse iteration is a
> RARE need -- far rarer than copying or even pickling -- and there
> is no real reason to burden __builtins__ with a function for it.

Is there any concern about the fact that a sequence of direction
changes requires building a new iterator object each time under this
proposal?  I was going to implement my own bidirectional iteration
protocol by using a prev() method and use an adaptor object to swap
the meaning of next() and prev().  Python iterators (and GoF
iterators) seem poorly suited as pure sequence position indicators
because you can't reposition them without also accessing elements, so
maybe this is not such a serious issue... but my instincts tell me
that the identity of a bidirectional iterator object could be useful
if we allow the same one to be used in both directions.

FWIW, burdening builtins aside I consider the proposed syntax

      for i in xrange(n).iter_backwards():

much uglier than

     for i in reverse_view(xrange(n)):

but far superior to

     for i in reverse(xrange(n)):

which implies in-place modification of the sequence.

Also, the idea of denying tuples the ability to reverse iterate seems
arbitrary and capricious.

Cheers,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com