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