Clark C. Evans wrote: > On Wed, Sep 08, 2004 at 09:33:10PM +0200, Samuele Pedroni wrote: > | Clark C. Evans wrote: > | >I was assuming that only calls within the generator to next(), implicit > | >or otherwise, would be suspension points. > | > | I missed that. > > *nod* I will fix the PEP. > > | >This covers all of my use cases anyway. In the other situations, if > | >they are even useful, don't do that. Convert the SuspendIteration to a > | >RuntimeError, or resume at the previous suspension point? > | > > | >The idea of the PEP was that a nested-generator context provides this > | >limited set of suspension points to make an implementation possible. > | > | then the PEP needs clarification because I had the impression that > | > | def g(src): > | data = src.read() > | yield data > | data = src.read() > | yield data > > The data producers would all be iterators, ones that that could > possibly raise SuspendIteration() from within their next() method. > > | the read itself could throw a SuspendIteration > > If read() did raise a SuspendIteration() exception, then it would > make sense to terminate the generator, perhaps with a RuntimeError. > I just hadn't considered this case. If someone has a clever > solution that makes this case work, great, but its not something > that I was contemplating. thinking about it, but this is not different: def g(src): data = src.next() yield data data = src.next() yield data def g(src): demand = src.next data = demand() yield data data = demand() yield data what is supposed to happen here, notice that you may know that src.next is an iterator 'next' at runtime but not at compile time.
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