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.

I 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.

Yielding 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

If so - Python 2.5.

Not 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...)

Good point. I had to re-read the article a couple times to figure out why this wasn't implemented as a generator. The Dunkels' TCP stack approach in C made more sense.