Most of Pythons standard library is sync, the minute you want to use a sync api from within async/await code it becomes a nightmare to manage.
If you are only using async library’s then async/await works perfectly.
If you are only using async library’s then async/await works perfectly.
Personally, I like that. An asynchronous function is different to a synchronous one, and if you call an asynchronous function the caller is asynchronous. The "colouring" just reflects the realities of the problem domain. I'm not keen on libraries that monkeypatch the world to hide that fact, as gevent does.
However, some people prefer those libraries. Which is fine. They both exist, use what you like. There's no need to have wars about it.
That's only true syntactically. If your sync function actually does any IO, it will block your async worker thread. Said differently it just synchronized your async code.
This results in ecosystem fragmentation though, which means that more effort is spent developing and maintaining different kind of solutions to the same problem, only because of their different developer experience.
On the contrary, look at Go, where it was decided from the beginning (i.e. stdlib) that we're going with coroutines.
It's a bit like (I'm exaggerating) arguing for what should be the default coding style, where a built-in/blessed formatter would make this a non-issue. gofmt is a nice example of this.
Also, honest question: AFAICT Python was more of the "there's 1 preferred way to do things". Doesn't arguing between async and coroutines goes against this mantra?
I've worked on several projects recently where async was used throughout and haven't had issues. There are many async libraries now, like ones to utilize GCP services, make HTTP calls, connect to Redis, etc.
What's wrong with sending the sync code to a thread pool? My CPU-, disk- and database-intensive application is filled with calls like:
result = await asyncio.to_thread(long_function())