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 -- http://mail.python.org/mailman/listinfo/python-list
