It solves an entire class of problems really nicely, and makes certain types of applications possible.
Once you've got your head around it - and that is not easy especially if you have not done much JavaScript - then it's almost magical.
For database access you can use asyncpg which is natively written as async. asyncpg is the fastest Python driver and faster than anything implemented on psycopg2.
Me too. I find it so much fun to write “web servers” with aiohttp that involve web sockets, coordination between multiple requests, message queues and more.
Agree, and for example quart is a really great framework for doing this kind of thing which is highly remeniscent of flask and handles cors and lots of the other shenanigans that are otherwise somewhat boring to deal with.
When you’ve written over one thousand event loops, and debug another thousand edge cases and logic bombs like reading a blocking socket before it’s ready, partial read, or mac vs Linux vs windows peculiarities in your homemade hundreds-lines long event loop, you will begin to appreciate letting go of it all, and letting python manage your event loop for you.
The fact that the author talks about using threading or M:N parallelism if he needed additional performance makes me think he doesn't really understand the use case for asynchronous programming. Async is specifically for the (very common) situation where a program has many clients (or servers) it needs to talk to but can't make progress efficiently because it spends a lot of time blocked on I/O. You can therefore handle these connections very efficiently without parallelism leaving other cores available to do other things. Threading and other parallelism techniques don't solve that same dillemma. If you create a large number of threads they will still be blocked on I/O waiting for clients or the network typically, and the existence of the GIL in python just makes the case for efficient multiplexing of I/O bound processes in single-threaded code (ie async) stronger. In the threaded case you have spent system resounces to create multiple threads that can't actually function in parallel (because they are blocked on I/O at least as often as the async event loop would be) and are now also sometimes blocked on the GIL.
Having decided that async is appropriate, the question is how you express that in a language or framework. I've used several approaches, from the magical "don't worry about it we'll just make it work for you" type of approach that he seems to advocate with gevent, to things like the callback-based approach of old Twisted (back in the days that python was a scrappy little upstart rather than this globally ubiquitous language). They are all equivalent from the machine's point of view more or less, but I find the async model easier to reason about and therefore easier to debug. This seems largely a question of taste. It's absolutely not the case that (as the author claims) the async versions of libraries are literally the same with just the word 'async' added into the function definitions. To take synchronous code and make it async, you have to reason about where your program spends its time, what parts of computation you can put into a future vs which parts belong in a seperate task etc. You can't just 's/def/async def/' add a few "awaits" and you're done.
The performance benefits can be very real if used well btw. As an example I have a request-heavy piece of code that used to take > 16hrs to run which took about 2.5mins once changed to async, and that's with adding rate limiting etc so I'm not flooding external servers with requests.
I love async Python.
It solves an entire class of problems really nicely, and makes certain types of applications possible.
Once you've got your head around it - and that is not easy especially if you have not done much JavaScript - then it's almost magical.
For database access you can use asyncpg which is natively written as async. asyncpg is the fastest Python driver and faster than anything implemented on psycopg2.
https://magicstack.github.io/asyncpg/current/
Huzzah for async Python!