Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
Nim
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
-
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
> Why not just use multi processing?
Multiprocessing provides parallelism up to what the machine supports, but no additional degree of concurrency, asyncio provides a fairly high degree of concurrency, but no parallelism.
OF course, you can use them together to get both.
https://github.com/omnilib/aiomultiprocess
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
I disagree. I've had a serious attempt at array typing using variadic generics and I'm not impressed. Python's type system has numerous issues... and now they just apply to any "ArrayWithNDimensions" type as well as any "ArrayWith2Dimenensions" type.
Variadic protocols don't exist; many operations like stacking are inexpressible; the synatx is awful and verbose; etc. etc.
I've written more about this here as part of my TorchTyping project: [0]
[0] https://github.com/patrick-kidger/torchtyping/issues/37#issu...
It's implemented in 3.11. Documentation still hasn't been written for it yet though and that's why the issue is still open, https://github.com/python/cpython/issues/90908.
One aspect of Pyright that seems decidedly not better is the 651 NPM dependencies [1] it apparently drags along.
[1] https://github.com/microsoft/pyright/blob/main/package-lock....
You might be (very) interested in this project then: https://deepkit.io/
The guy behind it made a PR to typescript proposing runtime availability of types[0], got rejected, and got going on it by himself. And he already has PoC libraries with the equivalent of Pydantic and FastAPI (using runtime types for (de)serialization).
I really hope this experiment works out and that it gains traction, because it's a massive value add to TS IMO.
[0] https://github.com/microsoft/TypeScript/issues/47658
You might be (very) interested in this project then: https://deepkit.io/
The guy behind it made a PR to typescript proposing runtime availability of types[0], got rejected, and got going on it by himself. And he already has PoC libraries with the equivalent of Pydantic and FastAPI (using runtime types for (de)serialization).
I really hope this experiment works out and that it gains traction, because it's a massive value add to TS IMO.
[0] https://github.com/microsoft/TypeScript/issues/47658
It looks like there's a PEP for that already! [0]
And as (almost) always, Pyright has already implemented the provisional PEP!
[0] https://github.com/python/mypy/issues/4441
> Box or anyhow::Error in these cases ergonomically
This comes at the cost of losing the precise information what error-types could occur and makes it harder to read the code compared to a language that can use its typesystem to model that.
> Your second point is dubious; I've never seen any crate use anything other than Result.
Maybe. And you also barely see something like Result being used in Python. Is that because Result is bad? No. It is because it is _hard_ to use Result in Python, both of the lack of ergonomy compared to e.g. exceptions and also because it's not standard and people will look at you funny.
So why is pretty much everyone in Rust using Result? Because using your own error-type causes exactly the problems that I mentioned (and more). So no matter how you look at it - this is a shortcoming of Rust and hopefully something that the Rust team will improve in the future. (E.g. https://github.com/rust-lang/rfcs/issues/324)
You should check out Nim. I wish more people would! https://nim-lang.org/
Unfortunately I couldn't find a good package either, so ended up rolling my own script, FnToCLI https://github.com/internetarchive/openlibrary/blob/master/s... . It wasn't too hard to get the bones of it working, so if you want to build something similar with built-in env handling, that might not be too bad! Under the hood it converts everything to argparse, so you can always use any complicated argparse options/etc if you want to.
The closest package was Typer, by the creator of FastAPI, but it looked unmaintained, and didn't support Literal types! Or at least that was the case when I was investigating ~year ago.