Python's yield was originally a limited co-routine, something we coined as a "generator" (borrowing the word from Icon, which Tim was quite fond of). It was limited to one frame on the stack and could only return values. Recent enhancements have allowed values to be passed back into the suspended function. That's still not a full co-routine though since Python only lets you go one level down on the stack.

As someone else mentioned, you need to get deeper into programming languages, not operating systems. Scheme has call/cc which can be used to build co-routines. Someone needs to clue in the nodejs crazies as well, callbacks are not the way to design a language. ;-)

All of the node.js kids get really defensive when you point this out; as if async was supposed to be heinously ugly despite the fact that the entire raison d'etre of node.js is to be async.

Programming advances so slowly because all of the training required to become familiar with it eventually becomes a blind spot.

It is hard to get excited about concurrency in vanilla Python while the Global Interpreter Lock still chokes everything down internally. (Vanilla, here, should be read "not Stackless.")

For more effective use of lightweight processes, I'd probably reach for Erlang or Occam.

Not sure why, the GIL is not an issue to node-style concurrency (based on an event loop and async IO), though you need alternative IO layers (Gevent provides exactly that, and can — if requested — monkeypatch the stdlib to replace standard synchronous IO calls by Gevent-provided async IO).

In fact, mixing threads and an event loop with async IO is probably a good way to make everything blow up.