[Zababa]

> If you have to deselect 20 default filters and then read through the frameworks in the list to see which ones are fully featured web frameworks in order to evaluate whether a library is suitably fast for your next project it is misleading.

It is not, this benchmark is purely about speed, not about being "suitable for your next project". You're the one adding all these other constraints. You only need to deselect some filters when you're doing something like comparing dynamic languages, which you did and wasn't even the initial claim discussed. I also doubt most people would call FastAPI "suitable for your next project" compared to something like Django or Flask that is already well known and maintained.

> But again, I'm not sure what this has to do with it being a high quality modern python library.

We're in a subthread discussing a claim on the FastAPI website that it's "Fast: Very high performance, on par with NodeJS and Go.", and how it's obviously wrong for Go, and possibly wrong for NodeJS.