Standard Asynchronous Python

[Bryan]

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 lament the confusion of generators and coroutines. Generators are no
substitute for threads; they're a substitute for temporary memory-
wasting lists and for those extraneous classes that just implement
another class's __iter__.

[big snip]
> As I get to work on the PEP, I'd like to hear any initial reactions to the idea.

Be warned that I'm frequently chastised for negativity...
Your motivating examples motivate me in the opposite direction.
Computing Fibonacci numbers with a generator? The problem with your
first support app is that threads don't scale?

I'm happy with the direction Python has chosen: real, platform-
provided threads. There are some fine projects taking other courses,
but most of the standard stuff is sequential code with some notion of
thread-safety. In this area Python has benefited for free as the
popular platforms have steadily improved.

Properly exploiting event-drive would be a bigger change than you
propose. Python tends to polymorphize I/O via "file like" objects,
who's requirements have traditionally been under-specified and have
never included event-driven behavior. Also, while Python is proudly
cross-platform, Microsoft Windows has the edge on asynchronous
facilities but Python treats Windows like a Unix wanna-be.

-Bryan