Chris Angelico <ros...@gmail.com>: > On Sat, Apr 18, 2015 at 1:47 PM, Paul Rubin <no.email@nospam.invalid> wrote: >> I don't remember anyone mentioning this here yet, and it is mighty cool: >> >> https://www.python.org/dev/peps/pep-0492/ > > [...] > > And yes, it IS cool. I think the current proposal has a lot of > duplication (it looks like there's almost a complete replica of the > generator protocol being created in parallel), but whatever happens, > it's a good thing.
I'm not sold on this coroutine fad. Deep down it's a rehash of the old false promise of thread programming: you can write reactive, scalable programs linearly. Reactive systems are complex and messy. In my experience the mess is managed most clearly when the participating state machines have a prominent place in the program text. IOW, you should *highlight* states with names that stick out. Threads and coroutines *downplay* states. Threads and coroutines look neat when they expect only one kind of input in any given state. At least coroutines (unlike threads) can be interrupted from the outside. However, implementing a state with multiple alternative stimuli easily results in lengthy, deeply-nested, messy code. To minimize the mess, what ends up happening is that you start one peripheral coroutine (or thread) per input source and have it convert the stimulus into method calls (callbacks). IOW, coroutines take the role of interrupt handlers. But then, I think that's a lot of conceptual and design machinery for such a simple thing. Callback dispatching from select.epoll() achieves the same objective. Now, the PEP proposal text mentions asynchronous database calls as an example. If coroutines are the price of asynchronizing database access, maybe the price is worth the prize. Marko -- https://mail.python.org/mailman/listinfo/python-list
