PEP 492, new coroutine syntax for Python

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> On Sat, Apr 18, 2015 at 1:47 PM, Paul Rubin <no.email at 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