Why are "broken iterators" broken?
roy at panix.com
Sun Sep 21 18:24:09 CEST 2008
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.
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.
More information about the Python-list