Send data to asyncio coroutine

[Marko Rauhamaa]

Javier <jcarmena at gmail.com>:

> Asyncio is a crazy headache! I realized that I can't use asyncio tcp
> servers with pickle! Asyncio is good as a concept but bad in real
> life.
>
> I think python's non blocking I/O is far from being something useful
> for developers till non-async code can invoke async code
> transparently. Duplicating all code/libs when you realize that
> something not fits asyncio is not a solution and even less a pythonic
> solution.

After all these decades, we are still struggling to find the naturally
flowing paradigm for asynchronous programming. Different
approaches/libraries/frameworks don't usually mix well or at all.

First, I believe it has been a grave mistake to write a ton of utility
libraries that block. They make it easy to put together a prototype, but
before long you realize the mess they have led you to and the only way
out is a complete rewrite or a number of complicated adapters that drain
performance, hurt quality and don't really add true value.

Could asyncio be the basis of a de-facto Python way of doing
asynchronous programming? Maybe. GvR definitely has that intention.
However, I'm afraid the paradigm is quite unnatural. Essentially, it is
thread programming where blocking calls are replaced with funny syntax.
Most developers are familiar with multithreading, but they often are not
actively aware what functions are blocking. Reading from a socket is
blocking. Writing to a socket is blocking as well. Is file I/O blocking?
Is database access blocking? Is socket.getaddrinfo() blocking?

A function may be nonblocking in one release of a package but might then
become blocking in the next release.

I'm an advocate of the "callback hell" together with clearly expressed
finite state machines. They are super easy to understand. They lead to
very complicated code but the complications can be analyzed and debugged
based on the elementary knowledge. Also, you don't need a complicated
framework for it. The only thing missing from select.epoll() is timers,
but timers are not all that hard to implement (especially if you had an
a balanced tree implementation at your disposal).

Still, even the select.epoll() method requires callback implementations
of the different protocols and databases.


Marko