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 -- https://mail.python.org/mailman/listinfo/python-list
