In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote: > > > According to the Python docs, once an iterator raises StopIteration, it > > should continue to raise StopIteration forever. Iterators that fail to > > behave in this fashion are deemed to be "broken": > > > > http://docs.python.org/lib/typeiter.html > > > > I don't understand the reasoning behind this. As I understand it, an > > iterator is something like a stream. There's no constraint that once a > > stream is empty it must remain empty forever. > > it's a design guideline, not an absolute rule. > > but I disagree that an iterator is "something like a stream". it's > rather "something like a pointer or an index", that is, an object that > helps you iterate over all members in a collection. > > </F> There are plausible examples of collections which grow while you're iterating over them. I'm thinking specifically of a queue in a multi-threaded application. One thread pushes work onto the back of the queue while another pops from the front. The queue could certainly go empty at times. But, maybe a Python iterator is just the wrong way to model such behavior. -- http://mail.python.org/mailman/listinfo/python-list
