[Guido] > ... > I think that for synchronized-like cases, even if it is known at > compile time that it is to be part of the surrounding scope, the code > generated will still need to use nested-scope-cells, since it will be > invoked on a different stack frame: the "thunk processor" pushes its > own frame on the stack, and I think you can't have something that > executes in a frame that's not the topmost frame. (Or can you? I > don't know exactly what generators can get away with.) "resumable function" captures almost all salient aspects of the Python generator implementation. Generator resumption acts like a method call to the resumer (generator_iterator.next(), whether explicit or implicit), and yielding acts *almost* like a function return to the generator (the generator's stack frame is popped just as for a function return; the primary difference is just that the frame's refcount isn't decremented). In short, the implementation is a way to get the same frame on the top of the stack more than once; there's nothing there now to support execution in a non-top frame. If such were added, the biggest mystery would be what to do when a non-top frame tries to exit.
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