El sábado, 1 de agosto de 2015, 19:19:00 (UTC+2), Marko Rauhamaa escribió: > Javier <jcarm...@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". -- https://mail.python.org/mailman/listinfo/python-list
