On Thu, 05 Nov 2015 03:59:05 +0000, Michael Selik <mike at selik.org> wrote: > > I'm not suggesting restarting at the top (I've elsewhere suggested that > > many such methods would be better as an *iterable* that can be restarted > > at the top by calling iter() multiple times, but that's not the same > > thing). I'm suggesting raising an exception other than StopIteration, so > > that this situation can be detected. If you are writing code that tries > > to resume iterating after the iterator has been exhausted, I have to > > ask: why? > > The most obvious case for me would be tailing a file. Loop over the lines > in the file, sleep, then do it again. There are many tasks analogous to > that scenario -- anything querying a shared resource. The 'file' iterator actually breaks the rules of iterators: it does *not* continue to raise StopIteration once it has been exhausted, if more input becomes available. Given that it is one of the most commonly used iterators (and I would not be surprised if other special-purpose iterators copied its design), this pattern does seem like a blocker for the proposal. --David
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