On Sat, Jul 20, 2002 at 10:09:23AM -0400, Aahz wrote: > > That's the scenario that bit me too. For me it was a little more difficult > > to find because it was wrapped in a few layers of chained transformations. > > I can't tell by the last element in the chain whether the first one is > > re-iterable or not. > > > > My suggestion (which was rejected by Guido) was to raise an error when an > > iterator's .next() method is called afer it raises StopIteration. This > > way, if I try to iterate over the result again at least I'll get and error > > like "IteratorExhaustedError" instead something that is indistinguishable > > from an iterator of an empty container. I hate silent errors. > > I'm still not understanding how this would help. When a chainable > transformer gets StopIteration, it should immediately return. What else > do you want to do? The tranformations are fine the way they are. The problem is the source - if the source is an exhausted iterator and you ask it for a new iterator it will happily return itself and report StopIteration on each .next(). This behavior is indistringuishable from a valid iterator on an empty container. What I would like is for iterators to return StopIteration exactly once and then switch to a different exception. This way the transformations will not need to care whether their upstream source is restartable or not - the exception will propagate through the entire chain and notify the consumer at the end of the chain that the source at the beginning of the chain is not re-iterable. I'm not suggesting that all iterator implementers much do this - having it on just the builtin iterators will be a great help. Right now I am using tricks like special-casing files and checking if iter(x) is x. It works but I hate it. Oren
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