AsyncIO

>> Why I hate it

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!

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.

Shameless plug for a short post/guide to “the good bits” of asyncio from a few years ago: https://charemza.name/blog/posts/python/asyncio/I-like-pytho...

the author stole all my thoughts that I thought today while trying to write some asyncio!

asyncio is fun to play with, but it is a menace to any production level project