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.
I must say I've just spent quite some time looking at both PEPs and discussions and I'm strongly in favor of PEP 563 right now... it does improve the performance of typed modules substantially (which is a big downside for me in typed codebases) -- PEP 649 improves the situation but still adds a considerable overhead to the import time.
I think that the numbers given from Inada Naoki https://mail.python.org/archives/list/[email protected]/... do sum it well.
Also, I don't see what will be made impossible at the pydantic side... from the bug list that's shown at https://github.com/samuelcolvin/pydantic/issues/2678, yes, the code needs to be adapted, but I don't see what's made impossible (maybe at some point the pydantic devs will actually say what the real problems are as so far no real concrete info on that was given).
Heck, they could even probably not even use `typing.get_type_hints()` (which currently apparently does an internal `eval()` and treat the annotation string however they'd like -- maybe more work, but then, absolute freedom to treat it as they see fit).
So, my plead goes the other way around: please don't make all projects which don't require runtime info from annotations pay the price for the few use cases which do use them (but don't make those impossible either -- but my take so far as that this is not the case).
FastAPI is just a rip off of Starlette, it's obvious when you look at the code (https://github.com/tiangolo/fastapi/tree/master/fastapi). Hopefully this change will kill FastAPI and force people to use the original project that is Starlette (https://www.starlette.io/)
As to why people used FastAPI instead of Starlette in the first place, it comes down to hype and great marketing.
It's easy to say, but pydantic exists, and automatic validation on top of dataclasses does not/there's no well-known, well-tested library? (I'd also prefer something other than pydantic that doesn't coerce types by default, but alas...)
And it's a huge use-case that should've been obvious. It's hard to see the point of using dataclasses - which require type annotations to work - when you can then corrupt them by passing in whatever? Hand-rolling validation also doesn't feel like batteries included.
More generally, there are already tools using type annotations, and there'd likely be more if it was robust. Python was generally good at enabling metaprogramming, but type annotations are a bit of a minefield. See even dataclass' own impl, e.g. [0]. And building on top of dataclasses is also tricky.
I'm hopeful it can be resolved. Type annotations are a huge boon to the language, and it's already no small feat to have added them without breaking backwards compatibility.
[0] https://github.com/python/cpython/blob/8a232c7b17a2e41ae14d8...
I'll shamelessly piggy-back here, and note that I'm working on a different type of type-safe validation library for python here: https://github.com/keithasaurus/koda.
I'm nearing an initial release, but am still working on some of the docs, naming, and things like that. If anyone had any feedback, I'd be grateful!
FastAPI is just a rip off of Starlette, it's obvious when you look at the code (https://github.com/tiangolo/fastapi/tree/master/fastapi). Hopefully this change will kill FastAPI and force people to use the original project that is Starlette (https://www.starlette.io/)
As to why people used FastAPI instead of Starlette in the first place, it comes down to hype and great marketing.
See also mypy and pyproject.toml support (https://github.com/python/mypy/issues/5205), although there's currently a PR in progress that'll hopefully put that to rest.
Ha! PEP 387 was edited yesterday in a way that does not make any the above wrong, but does mean you'll be confused if you go looking for my quote: https://github.com/python/peps/commit/307b9cdf8897cbade62773....