Because I don't need it.

When I need to do concurrent stuff I either use fork to multiprocess or use the threading library, no import necessary, couple of lines of code, no need to make specialized code with await keywords and stuff.

This line made me question myself though:

"Then Flask is and probably always will be synchronous (Quart is an async alternative with similar APIs)."

I use flask, and I literally spent the last hour questioning whether I was an idiot and needed to dm my previous clients asking them to fix my code. I'm wondering how my apps passed stress tests of thousands of concurrent users, maybe I did the tests wrong?

Chatgpt says

"s flask asynchronous? ChatGPT said:

Flask itself is not asynchronous. It is a WSGI-based framework, which means it is synchronous by design — it handles one request at a time per worker. Each request is processed sequentially, and concurrency is typically achieved by running multiple worker processes"

Oh shit, I didn't use gunicorn, I just run the python script raw. I'm an idiot. Let's write a test server that sleeps for 1 second before responding to a request:

" import flask import requests import time app = flask.Flask("test")

@app.route("/") def hi(): time.sleep(1) #requests.get("https://google.com") return "Hello, World!"

app.run("0.0.0.0",8088) "

This should block for like 25ms, if 50 concurrent users ask for this resource, there will be an average 500ms of extra latency!

And a Test client that does 50 calls at once, will it take 50 seconds?:

"import threading import requests

URL = "http://127.0.0.1:8088/"

def make_request(i): try: print("req") response = requests.get(URL) print("res") except: print("fail")

threads = []

for i in range(5): t = threading.Thread(target=make_request, args=(i,)) threads.append(t) t.start()

for t in threads: t.join()

print("All requests completed")

"

Then we run with time binary in linux:

>time python3 client.py

All requests completed

real 0m1.216s user 0m0.203s sys 0m0.039s

Ok, turn off the alarms, Flask is fine.

I'm not sure what's going on with async, but the only experience I had with it was a junior dev that came from writing horrible node apps with react and nest (his frontend connected to a supabase db directly with credentials exposed, even if there was a node backend).

He wanted to pivot to python because that's what I used and I had good results, so he installed Quartz instead of Flask, and he was writing Node like code in python, and it was of course a mess.

Not saying that it's always going to be a mess, but you are better off learning the native way of a language instead of trying to shoehorn other abstractions and claiming that the way it is done in python is inefficient, it's one of the most popular languages in the world, these are massively used libraries, it's unlikely that "something is terribly wrong". It's more of a meme that python is slow.

What async is, is an alternative and supposedly cleaner abstraction to do multithreading. What ends up happening is that people use it without understanding multithreading and operating systems in general, they just think that they need to use it to get parallelism.

There's 15 solutions to do parallelism, 1 is the native, vanilla solution (threading library), then there's 3 additional experimental ways in the standard library or futures library, and 11 solutions that you need to pip install. Newbies ask chatgpt or see a stackoverflow thread (or come from node), and they have a 1 in 15 chance of using the regular solution that newbies should be using, because they can't distinguish the wheat from the chaffe.

OP might have suffered from this and even believed that this 15th "async" way to do concurrency was the only way, and is judging python's concurrency by this feature. OP maybe believes that python is just now getting multithreading support? That we are all cavemen running toy applications that server 2 or 3 users? Word to the wise, focus on features that have existed on early versions like python2 BEFORE you focus on features that are being introduced in the later versions like 3.14, this in general, you should first learn how a UNIX machine from the 90s did its thing before you learn the kubernetes spark majiggy