At 09:30 PM 9/30/04 +0200, Leopold Toetsch wrote: >Please note that that has nothing to do with "aync programming". Its just >like a GOTO, but w/o limitation where you'll branch to - or almost no >limitations: you can't cross C-stack boundaries on in other words you >can't branch to other incarnations of the run-loop. (Exceptions are a bit >more flexible though, but they still can only jump "up" the C-stack) > >Using CPS for function calls implies therefore a non-trivial rewrite of >CPython, which OTOH and AFAIK is already available as Stackless Python. Clark is talking about a limited subset of CPS, where continuations are only single-use. That is, a very limited form of continuations roughly equivalent in power to either Greenlets or a stack of generator-iterators. >Making continuations usable at the language level is a different thing, >though. Indeed, and luckily it isn't needed for PEP 334. PEP 334 just needs the interpreter to be able to resume evaluation of a generator frame at any CALL opcode or "for" looping that invokes a generator-iterator's next() method, if SuspendIteration was raised. I don't know if a corresponding operation for Jython is possible. (In the case of CPython, this could be implemented via a type slot to check whether a callable object is "resumable", so that you actually *could* decorate suitable functions as being resumable, not just generator-iterator next() methods.) Personally, I'm +0 (at most) on the PEP at the moment, as it doesn't IMO add much over using a generator stack, such as what I use in 'peak.events'. I'd be much more interested in a way to pass values and exceptions *into* generators, which would be more in line with what I'd consider "simple coroutines". A mechanism to pass values or exceptions into generators would be let me replace the hackish bits of 'peak.events' with clean language features, but I'm not sure PEP 334 would give me enough to be worth reorganizing my code, as it's presently defined. Also, I find the current PEP a confusing mishmash of references to various technologies (that are all harder to implement than what's actually desires) and unmotivating implementations of things I'd can't see wanting to do. It would be helpful for it to focus on motivating usage examples (such as suspending a report while waiting for a database) *early* in the PEP, rather than burying them at the end. And, most of the sample Python code looks to me like examples of how an implementation might work, but they don't illustrate the intended semantics well, nor do they really help with designing an implementation. Finally, the PEP shouldn't call these co-routines, as co-routines are able to "return" values to other co-routines. The title should be something more like "Resuming Generators after SuspendIteration", which much more accurately describes the scope of the desired result.
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