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