[bigstrat2003]

Performance aside (which I would argue is premature optimization, as most programs will not feel the theoretical overhead of threads), async is a bad approach for developer ergonomics. Threads are so much easier to work with and reason about than async. There are reasons to use async (like if you're in the rare case when thread overhead is noticeable), but developer ergonomics are absolutely not a reason.

[seabrookmx]

Say I need the results from two expensive REST API calls, so I want to run them concurrently. Managing a thread pool you find a _better_ experience than

one, two = await asyncio.gather(callOne(), callTwo())

?

[wtetzner]

Doesn't Python support futures?

    with ThreadPoolExecutor() as executor:
        one, two = executor.map(lambda f: f(), [callOne, callTwo])

I'm sure you could write a nicer helper function that's more similar to gather as well.

[seabrookmx]

Sure, in a web server context you'd probably want to instantiate that executor globally and re-use it, Then you could write helper functions around that. But it's still considerably more code and legwork than the async alternative, while also being slower and using more memory if you care about those things.