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?
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