Web development in Python is a lot of fun nowadays and has scaled just fine (we serve a few billion requests/ month). FastAPI makes writing APIs easy as well (it powers https://internetdb.shodan.io) and for deployment check out uWSGI or uvicorn.

> few billion requests/ month

A billion requests per month is 400 requests per second. My toaster can do better than that :)

Not to say that your product isn’t capable for many use cases, but the fact that the 1krps range is something impressive in Python world is indicative of the issue: Python is not built for speed, it’s built for convenience, and increasingly it’s competing against more modern languages that offer both.

It can do a lot more and I didn't say it was impressive. What I am saying is that Python won't be the bottleneck for the vast majority of websites and that it will scale. And the raw performance of the underlying language is rarely the thing you need to worry about when writing a website. If you like Python then there are a lot of robust options available to create a product that scales.

FastAPI will always be relegated to the backwater of Python frameworks for as long as Tiangolo doesn’t bother allowing the community to improve it.

I'm curious, how is FastAPI "relegated to the backwater of Python frameworks" when it is the fastest growing (by popularity) Python web framework[0], and it has the endorsement of the folks behind some of the most used Python frameworks, as well as adoption by everyone ranging from small startups to the largest corporations[1]?

[0] https://star-history.com/#tiangolo/fastapi&django/django&pal...

[1] https://github.com/tiangolo/fastapi#opinions

> as long as Tiangolo doesn’t bother allowing the community to improve it.

I don't see it that way. I see a rapidly growing library still in pre-1.0 and a BDFL trying to wade through a mountain of "contributions", a lot of them garbage, trying to keep code quality high in one of the most pristine and readable source code repos I've ever seen.

Also they have crowdsourced 17 languages for documentation translation. And it's up to date. That's bonkers. You're lucky if english documentation is accurate and up to date in many open source codebases.

Lol @ “keeping code quality high”. Have you even looked through his source code? You know, the one with functions spanning dozens of parameters that literally have no actual documentation?

Give me a fucking break. Let’s not even talk about the fact that it has well over a thousand open “questions”.

Yeah, actually, I'm super well acquainted with it, are you? Normally I hate the "self-documenting code" trope, but in this case, actually think the vast majority of these parameters are actually self-documenting, and also, everything is type-annotated. Let's take a snippet from the Dependant class:

    class Dependant:
        def __init__(
            self,
            *,
            path_params: Optional[List[ModelField]] = None,
            query_params: Optional[List[ModelField]] = None,
            header_params: Optional[List[ModelField]] = None,

What are path_params? They're params parsed from the URL path. What are query params? The same, from URL query component. Header params? Params pulled from the request headers. Shocking. If you actually sit down and read through FastAPI it's remarkably easy to get your bearings and start hacking around, despite the "no actual documentation" (I think type annotations count as documentation).

Compare that to code bases like Django, Celery, Matplotlib, where it's kwargs, kwargs, everywhere and nary a type hint to speak of.

The number of open issues is due to the massive popularity of the library (46K stars) compared to the number of actual maintainers. Some actual questions on the Issues tab right now:

- How to add admin page? - Is safe to remove value from list in asyncio - Best practice to run FastAPI on Cloud Run with server port as $PORT

These are all n00b questions that could readily be answered with general-purpose resources, but this is the blight that super popular FOSS libs and their maintainers have to deal with.

Lol @ that example.

https://github.com/tiangolo/fastapi/blob/master/fastapi/rout...

But yeah, code is documentation!!! We don’t need any actual API docs!!! All hail tiangolo!

I'm in fact super acclimated with that file in particular. I've had zero problem jumping in and hacking around with it (been trying to cook up a FastAPI-like endpoint interface for async jobs/tasks a la Celery). Not a single line is surprising if you slow down and actually read the code - and I consider myself less-than-great at actually reading other people's code. It took me all of ... 15 minutes to find my way around, figure out the machinery I needed to hijack, and maybe another 45 to get a crude MVP of my concept working.

Honestly I prefer it over reading documentation and then having to mentally map to the codebase. I wish I could write this code well.

You sure you've actually read any of it, or did you just skim, see no docstrings, and decide it's crap?

Is this an example of Stockholm syndrome

My perception is that FastAPI is one of the most celebrated Python libs that gained traction in recent years.

Could you please elaborate?

Actually my primary use is CLIs, integrations, and such. It used to be a great systems language (1.6-1.8, 2.x). But now I can’t rely on an OS having a reasonable version, or of libraries, so there’s the distribution problem.

It’s really only good for apps or things I (or other Python people) are going to run.

Part of it is that I don’t do analytics work. Now that PERL is niche, my use cases are no longer the target.