Standard Asynchronous Python

[Dustin J. Mitchell]

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