Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastAPI 0.100.0 release notes

fastapi.tiangolo.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: FastAPI 0.100.0 release notes

#91

Post by scolvin »

LtWorf wrote: post #35
agent281 wrote: post #15

Earlier quoted context omitted.

Pydantic was a pure python library and was rewritten in Rust recently. To be fair, I have seen some critiques of this rewrite. Specifically saying that the validation model could have been much faster in Python and switching languages papers over the deficiencies. I'm not in a good place to judge if this is true or not.

I wrote so in other comments… I was surprised to see that for the benchmarks of my library (typedload), it now manages to win a few… but not all of them.

would love to see a benchmark where typedload is faster than Pydantic V2. Could you share a link?

Re: FastAPI 0.100.0 release notes

#92

Post by xctr94 »

_Algernon_ wrote: post #71
TheRealPomax wrote: post #61

Earlier quoted context omitted.

No, they don't. They literally link out to semver.org

The joke . . . Your head

https://www.scienceofpeople.com/sarcasm-why-it-hurts-us/

Sarcasm isn’t funny to everyone; GP was understandably confused. This isn’t Reddit.

Re: FastAPI 0.100.0 release notes

#93

Post by LtWorf »

scolvin wrote: post #91
LtWorf wrote: post #35

Earlier quoted context omitted.

I wrote so in other comments… I was surprised to see that for the benchmarks of my library (typedload), it now manages to win a few… but not all of them.

would love to see a benchmark where typedload is faster than Pydantic V2. Could you share a link?

You realise that you made version2 3 days ago?

I re-do the benchmarks of typedload when I make a release. The benchmarks will be updated when the next release happens.

I will not do a new release because you need new benchmarks after 3 days. You are free to include benchmarks on your own website (but we both know you won't do that).

This is because of how my whole setup works, requiring a git tag and a finished CHANGELOG. Running the command to regenerate the website would cause documentation from the master branch to be published.

The benchmarks will be here, as usual. https://ltworf.github.io/typedload/performance.html

I run them just getting the latest available version. But since I can't time travel, I can't get versions from the future to appease you, sorry.

I just ran them locally (like you could do by yourself) https://news.ycombinator.com/item?id=36644818

Re: FastAPI 0.100.0 release notes

#94

Post by LtWorf »

scolvin wrote: post #85
LtWorf wrote: post #32

Earlier quoted context omitted.

Well the performance increase is so huge because pydantic1 is really really slow. And for using rust, I'd have expected more tbh… I've been benchmarking pydantic v2 against typedload (which I write) and despite the rust, it still manages to be slower than pure python in some benchmarks. The ones on the website are still about comparing to v1 because v2 was not out yet at the time of the last release. pydantic's autho…

This is simply not true. So sad. We removed benchmarks from the docs completely when the rule of "only show benchmarks with comparatively popular or more popular libraries" no longer made sense, and maintaining benchmarks with many hobby packages was obviously going to become burdensome. Please show me a sensible benchmark where your library is faster than pydantic?

> This is simply not true. So sad.

Ah sorry, so, just coincidentally pydantic happened to be slower than any other library that had a PR to be added to the benchmark, but that was not the reason they were rejected.

Better now?

> Please show me a sensible benchmark where your library is faster than pydantic?

    $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --pydantic
    (1.2192879340145737, 1.2595951650291681)
    $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --typedload
    (1.0874736839905381, 1.114147917018272)
I'm not a math genius but I'm fairly sure that 1.08 is less than 1.21.

So much for your invite to be gentle and cooperative :D (https://github.com/ltworf/typedload/pull/422)

Re: FastAPI 0.100.0 release notes

#95

Post by TheRealPomax »

Aeolun wrote: post #90
TheRealPomax wrote: post #65

Earlier quoted context omitted.

Yeah, doesn't stroke well with "FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly." now does it? It doesn't matter how quickly you move, you can apply real semver numbering just fine. Five years and a 0 dot one hundred is obeying the letter of the law while being utterly ridiculous.

Or maybe the people using a thing under development that could constantly change in production are ridiculous?

If that were the case, then the docs would call that out and warn people not to use their project in production. Instead, it's listed in a way that any normal person will read as a point of pride.

Re: FastAPI 0.100.0 release notes

#96

Post by btreecat »

andrewstuart wrote: post #84
v3ss0n wrote: post #77

Earlier quoted context omitted.

Traefik would be much better proxy if you are using container based dev. Also Please give litestar a try.

I’m not a fan of the complexity of containers or kubernetes. Everything I’ve built scales vertically on bare OS very nicely. Regarding litestar, if I wanted to do Python web development I’d use Starlette, which I really liked, but I’ll probably stick with nodejs and typescript from here for web applications.

Great, so we just gotta "ship your bare OS" to prod.

That's exactly what a container is for.

Container is just a logical isolation tool that works at the distribution/deployment level.

Re: FastAPI 0.100.0 release notes

#97

Post by v3ss0n »

andrewstuart wrote: post #84
v3ss0n wrote: post #77

Earlier quoted context omitted.

Traefik would be much better proxy if you are using container based dev. Also Please give litestar a try.

I’m not a fan of the complexity of containers or kubernetes. Everything I’ve built scales vertically on bare OS very nicely. Regarding litestar, if I wanted to do Python web development I’d use Starlette, which I really liked, but I’ll probably stick with nodejs and typescript from here for web applications.

K8s is complicated , but Docker (docker compose) solves a lot of problems especially when you are working with a team. Just 5-10 lines of YAML code in your docker-compose.yaml file and it gives you an local infrastructure of db , redis , node , python , nginx and many other things. Then you can share with anyone in your team , and it works on their machine too. Don't afraid of time saving tech.

We had use nodejs/ts , but nothing meets DX of python , or Python + MyPy yet, and ecosystem is unmatched.

Re: FastAPI 0.100.0 release notes

#98

Post by scolvin »

LtWorf wrote: post #94
scolvin wrote: post #85

Earlier quoted context omitted.

This is simply not true. So sad. We removed benchmarks from the docs completely when the rule of "only show benchmarks with comparatively popular or more popular libraries" no longer made sense, and maintaining benchmarks with many hobby packages was obviously going to become burdensome. Please show me a sensible benchmark where your library is faster than pydantic?

> This is simply not true. So sad. Ah sorry, so, just coincidentally pydantic happened to be slower than any other library that had a PR to be added to the benchmark, but that was not the reason they were rejected. Better now? > Please show me a sensible benchmark where your library is faster than pydantic? $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --pydantic (1.2192879340145737, 1.259595165…

¯\_(ツ)_/¯ - I get different results, see the PR.

Re: FastAPI 0.100.0 release notes

#99

Post by v3ss0n »

delijati wrote: post #87
v3ss0n wrote: post #50

https://litestar.dev is also reaching 2.0 .it is a lot faster than FastAPI yet much better maintained. Has DTO, event and channels, Repository, Service DDD style framework built-in. No promotional commits. I had written the reason of moving away from FastApi here and intro to Litestar 2.0. https://dev.to/v3ss0n/litestar-20-beta-speed-of-light-power-...

Has litestar CBV (class based views) fastapi refuses to implement them so we build [1]. Or proper lifetime event [2]? [1] https://github.com/KiraPC/fastapi-router-controller [2] https://github.com/tiangolo/fastapi/issues/617

Yes litestar have class based controllers since day one , class based views with HTMX/Jinja is also available in 2.0 which is now nearing release. Here is lifecycle management : https://docs.litestar.dev/2/usage/the-litestar-app.html#star...

  app = Litestar(on_startup=[get_db_connection], on_shutdown=[close_db_connection])
We have quite powerful channels and event systems that goes along with websocket and realtime systems too.

Plus , if you use Repository + Sqlalchmey Plugin and DTO , you can also work with CRUD events before_update/after_update/before_insert/after_instet etc

Re: FastAPI 0.100.0 release notes

#100

Post by scolvin »

nerdponx wrote: post #57
ramraj07 wrote: post #41

Earlier quoted context omitted.

Could you simplify your point? I was an ardent marshmallow user and when I finally switched to pydantic, it felt like I finally sat down in my life after standing forever. The documentation sounds good enough to me, but importantly the interface pydantic provides to define your json schema is the most elegant interface I’ve seen in any language and miles better than the mess marshmallow provided. For many of us espec…

There is no reference doc. The docs cover a lot of material in a small amount of space, buying important pieces of information and mixing up a large number of topics under unintuitive headlines. Reading the source code is occasionally necessary just to figure out how it all works. The API is a little weird, particularly around defining validators. The parameter name-matching is an "interesting" design choice. Accessi…

Please please take a look at V2, both the code and the documentation (although I admit, the documentation for V2 isn't finished).

I (the developer of Pydantic) had many of the same frustrations with Pydantic V2 which is why I've spent so long rewriting it to try and fix these concerns.

In particular:

* we now have API documentation [1] * we have first class support for validating `TypedDict` which gives you a typing-valid dict representation of your data straight out of validation * we now have strict mode * we're working hard to define an exact spec for what validates to what [2] * we have a strict separation between public/private - everything private is in a `pydantic._internal` module, and we have unit tests that everything which can be publicly imported is explicitly public * we now use `Annotated[]` for defining custom validations/constraints, together with annotated-types [3] * the protocol for customising validation and serialization has been significantly improved [4]

I'd really love to hear your feedback on V2 and what more we can do to improve it - your feedback seem unusual reasonable for HN ;-) - please email samuel@pydantic.dev or create an issue/discussion if you have any thoughts.

1: https://docs.pydantic.dev/latest/api/main/ 2: https://docs.pydantic.dev/latest/usage/conversion_table/ 3: https://github.com/annotated-types/annotated-types 4: https://docs.pydantic.dev/latest/usage/types/custom/

Post reply on HN