3 ms·
A "generator" is a subtype of coroutine. Python calls them "generators" because 1) that's what Icon called them, and 2) Python's implementation of coroutines is
by silentbicycle 17y ago
A "generator" is a subtype of coroutine. Python calls them "generators" because 1) that's what Icon called them, and 2) Python's implementation of coroutines is* restricted by being unable to yield from within called functions, among other things, so they're not as generally useful.
* Was? Maybe Python 3 fixed this. I use Lua instead now -- it's cleaner, consistently gets these things (TCO, lambdas, coroutines, the GIL, etc.) right, and I'm not going to wait forever for Guido to change his mind.
- cturner 17y agoYielding from within called functions is the basic generator syntax, but I think I know what you're talking about. > Maybe Python 3 fixed this Can you verify that this is what is being talked about at page 26 of this link? http://www.dabeaz.com/coroutines/Coroutines.pdf http://www.dabeaz.com/coroutines/Coroutines.pdf If so - Python 2.5.
- silentbicycle 17y agoNot slide or page 26, no. From PEP 342: Also, generators cannot yield control while other functions are executing, unless those functions are themselves expressed as generators, and the outer generator is written to yield in response to values yielded by the inner generator. This complicates the implementation of even relatively simple use cases like asynchronous communications, because calling any functions either requires the generator to "block" (i.e. be unable to yield control), or else a lot of boilerplate looping code must be added around every needed function call. It looks like 2.5 fixed that particular issue. (I'm not holding my breath on tail-call optimization, though...)
- abecedarius 17y agoI followed the language of Beazley's slides on Python coroutines: a 'generator' is a thing like this: def g(): for i in range(10): yield i and a 'coroutine' is a thing like this: @coroutine def c(): while True: x = yield print x The code in the original post is like the latter. g() produces successive outputs when you call .next() on it; c() consumes successive inputs when you call .send(input) on it. The g() style has been in Python longer and is better integrated into the language -- you can say "for x in g():", for example. That's the point I was making, maybe too tersely. Your point 2 is still correct, though there's a PEP to make trampolining to work around it work nicer.