Standard Asynchronous Python

[Steven D'Aprano]

On Sun, 09 Sep 2012 20:07:51 -0400, Dustin J. Mitchell wrote:

> After seeing David Mertz's talk at PyCon 2012, "Coroutines, event loops,
> and the history of Python generators" [1], I got thinking again about
> Python's expressive power for asynchronous programming.
[...]
> I'm considering re-drafting the PEP with the following changes:
> 
>  * De-emphasize the thread emulation aspects, and focus on
> code-portability issues:
>    * callbacks vs. "blocking" calls (e.g., when accepting incoming
> connections on a socket, how is my code invoked?)
>    * consistent access to primitives, regardless of framework (e.g.,
> where's the function I call to branch execution?)
>    * nested asynchronous methods
>  * Account for PEP 380 (by making the StopIteration workarounds match
> PEP 380, and explicitly deprecating them after Python 3.3)
>  * Look forward to a world with software transactional memory [5] by
> matching that API where appropriate
> 
> As I get to work on the PEP, I'd like to hear any initial reactions to
> the idea.

My reaction is that until your framework gets some significant real-world 
use, it probably doesn't belong in the standard library. To some degree, 
the standard library is where good code goes to die -- the API should be 
mature and well-tested, not just the code, because we'll be stuck with 
the API (essentially) forever. Code can change, bugs can be fixed, but 
we're stuck with "referer" forever :)

At least, you should be prepared to justified why your library uthreads 
should be considered mature enough for the std lib despite the lack of 
real-world use. 



-- 
Steven