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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4