[Python-Dev] Single- vs. Multi-pass iterability

[Andrew Koenig]

Ping> Just fetch the iterator from the container and look for __copy__ on that.

Yes, that's an alternative.

However the purpose my suggestion of __multiter__ was not to use it to
test for multiple iteration, but to enable a container to be able to
yield either a single or a multiple iterator on request.

Ping> Or, what if there is no container to begin with, but the iterator is still
Ping> copyable?  You can't flag that by putting __multiter__ on anything; again
Ping> it makes more sense to just provide __copy__ on the iterator.

You could flag it by putting __multiter__ on the iterator, just as iterators
presently have __iter__.

Ping> All that's really necessary here is to document the convention about what
Ping> __copy__ is supposed to mean if it's available on an iterator.  If we
Ping> all agree that __copy__ should preserve an independent copy of the
Ping> current state of the iterator, we're all set.

Not quite.  We also need an agreement that calling __iter__ on a container
is not a destructive operation unless you call next() on the iterator that
you get back.

>> Another reason is that I can imagine this idea extended to encompass,
>> say, ambidextrous iterators that support prev() as well as next(),
>> and I would want to use __ambiter__ as a marker for those rather
>> than having to create an iterator and see if it has prev().

Ping> I think a proliferation of iterator-fetching methods would be a
Ping> messy and unpleasant prospect.  After __iter__, __multiter__,
Ping> and __ambiter__, what next?  __mutableiter__?
Ping> __depthfirstiter__?  __breadthfirstiter__?

A data structure that supports several different kinds of iteration
has to provide that support somehow.  What's your suggestion?