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

[Ka-Ping Yee]

On Thu, 11 Jul 2002, Andrew Koenig wrote:
> More seriously, I can imagine distinguishing a multiple iterator by
> the presence of __copy__, but I can't imagine using the presence of
> __copy__ to determine whether a *container* supports multiple
> iteration.  For example, there surely exist containers today that
> support __copy__ but whose __iter__ methods yield iterators that do
> not themselves support __copy__.

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

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

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

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

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


-- ?!ng

"If I have seen farther than others, it is because I was standing on a
really big heap of midgets."
    -- K. Eric Drexler