Why are "broken iterators" broken?

[Roy Smith]

In article <mailman.1327.1222010852.3487.python-list at python.org>,
 Fredrik Lundh <fredrik at pythonware.com> 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.