[necovek]

Indeed, it's surprising that someone is building today a framework in Python that is not async, when it's pretty easy to do so (compared to eg. the twisted days, but even to pre3.6 days).

[mixmastamyk]

Async is not helpful for most projects and complicates the rest.

[zedpm]

That's an odd assertion. What kind of things do you think most projects do? I'd say most projects have network IO happening (querying databases, storing data to e.g. S3, communicating with other web services), in which case async absolutely is helpful and far more performant.

[mixmastamyk]

https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a...

[zedpm]

That's nearly 5 years old now, so even the bits of that which are backed up with actual data aren't of much use. Benchmarks of asyncio in python 3.4.1 are going to be wildly different than in later versions. I understand the argument he's trying to make about db access and performance, but modern benchmarks seem to disprove his argument, e.g. https://www.techempower.com/benchmarks/#section=data-r18&hw=... and https://www.techempower.com/benchmarks/#section=data-r18&hw=... .

[mixmastamyk]

Not sure what I’m looking for.

[necovek]

In the second URL, most async frameworks can deliver around 10x the number of http request for endpoints doing 20 sql queries to pg (15000 vs 1500 for flask/django...).

Note that this thread is a discussion of a new web framework — one that will definitely do network requests, and likely to do db requests (over a network or a local socket, but I/O bound regardless).

[zedpm]

Yes, sorry, those are benchmarks for python web frameworks making db queries. All the top performers are async frameworks.

[caro_douglos]

While async is a huge plus of fast api I’ve found the documentation creation to be the most helpful. My 2c.