"Frank Millman" <fr...@chagford.com>: > Then Twisted made a strong case for an asynchronous approach. One of > their claims (which I have no reason to doubt) was that, because each > user 'session' spends most of its time waiting for something - > keyboard input, reply from database, etc - their approach allows > hundreds of concurrent users, something that I believe would not be > possible with threading or multi-processing.
You don't need asyncio to do event-driven programming in Python. I have programmed several event-driven applications in Python (and even more of them in other languages) without using asyncio (you only need select.epoll()). My favorite model is the so-called "callback hell" with explicit finite state machines. That tried-and-true model has always been used with parallel, concurrent and network programming as well as user-interface programming. Your code should closely resemble this: <URL: http://www.bayfronttechnologies.com/capesdl.gif> Multiprocessing is also an important tool for compartmentalizing and parallelizing functionality. Threads are mainly suitable for turning obnoxious blocking APIs into nonblocking ones, but even there, I would prefer to give that job to separate processes. Marko -- https://mail.python.org/mailman/listinfo/python-list
