The responses have certainly highlighted some errors in emphasis in my approach.
* My idea is to propose a design PEP. (Steven, Dennis) I'm not at *all* suggesting including uthreads in the standard library. It's a toy implementation I used to develop my ideas. I think of this as a much smaller idea in the same vein as the DBAPI (PEP 249): a common set of expectations that allows portability. * I'd like to set aside the issue of threads vs. event-driven programming. There are legitimate reasons to do both, and the healthy ecosystem of frameworks for the latter indicates at least some people are interested. My idea is to introduce a tiny bit of coherence across those frameworks. * (Bryan) The Fibonacci example is a simple example of, among other things, a CPU-bound, recursive task -- something that many async frameworks don't handle fairly right now. I will add some text to call that out explicitly. * Regarding generators vs. coroutines (Bryan), I use the terms generator and generator function in the PEP carefully, as that's what the syntactic and runtime concepts are called in Python. I will include a paragraph distinguishing the two. I will need to take up the details of the idea with the developers of the async frameworks themselves, and get some agreement before actually proposing the PEP. However, among this group I'm interested to know whether this is an appropriate use of a design PEP. That's why I posted my old and flawed PEP text, rather than re-drafting first. Thanks for the responses so far! Dustin -- http://mail.python.org/mailman/listinfo/python-list