Send data to asyncio coroutine

[Javier]

El sábado, 1 de agosto de 2015, 19:19:00 (UTC+2), Marko Rauhamaa  escribió:
> 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

I agree with you, Marko, I came from callbacks too. So, if GvR wants the yield from become de-facto, does it mean that all python libraries will evolve to become asyncio friendly libs? or that I have to write my own library so I can use existing libraries like pickle? I think "callback hell" is "peccata minuta" compared with "yield from hell".