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

81–90 of 115 posts

Re: FastAPI 0.100.0 release notes

#81

Post by tomtom1337 »

Kydlaw wrote: post #24
nikcub wrote: post #21

The rustification of Python libraries and tooling continues and it has been brilliant. In the past 6 months I have personally switched projected to ruff[0], polars and now - as of this morning[1] - pydantic 2 and FastAPI 0.100 [0] has replaced pylint, flake8, pyupgrade, isort, mccabe and pydocstyle [1] bump-pydantic worked well, after porting settings to pydantic_settings.

You might want to check Pylyzer then ( https://github.com/mtshiba/pylyzer ). I'm not involved at all. It is still very very early in development. But as it is in the same vein, I thought I'd mentioned it here.

Have you actually got it working as an LSP server? I tried about a month ago without success.

Edit: Scratch that, had a go now with no trouble, passing `pylyzer --server` from my editor (helix).

Re: FastAPI 0.100.0 release notes

#82

Post by rewmie »

senko wrote: post #11
TheRealPomax wrote: post #7

> 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. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ )

> This is semver:

This is a good example of people confusing the letter of the law with the spirit of the law.

Semver is not a goal onto itself. Semver expresses a process to help consumers of an interface infer the implications of an upgrade without having any context on what specifics went into a release. Major changes imply breaking changes, minor changes imply addition of backward compatible changes which can prevent future downgrades, and patch releases means a drop-in replacement that fixes bugs.

Each and every single one of these scenarios reflect decisions made by product maintainers on their work's reliability. Semver is the tool, not the cause.

If product maintainers do not care about stable versions, it makes no difference if they comply with semver or not. What number they tack onto a release means nothing. They might as well tag a timestamp.

If they cared about ensuring their consumers that their work is reliable and stable but still reserve the right to break changes, they could blindly do major version releases and even drop any contract testing from their pipelines. They could even go a step further and claim they only support the N last major releases.

Nevertheless, competent maintainers and product managers know beforehand what is supposed to ship with a release, and even plan when and how to ship those changes. If anyone knows beforehand what changes go in a release, they can easily tell beforehand if that release should be major, minor, or patch. This is not rocket science.

Re: FastAPI 0.100.0 release notes

#83

Post by [deleted] »

senko wrote: post #11
TheRealPomax wrote: post #7

> 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. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ )

[deleted]

Re: FastAPI 0.100.0 release notes

#84

Post by andrewstuart »

v3ss0n wrote: post #77
andrewstuart wrote: post #76

Over 14 years or so I’ve developed major applications with flask, bottle, Falcon, FastAPI, Django, Sanic and Starlette. My preferred back end web server is now nodejs with typescript and plain old Postgres SQL queries, no ORM. Caddy web server with auth sub requests.

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.

Re: FastAPI 0.100.0 release notes

#85

Post by scolvin »

LtWorf wrote: post #32
krat0sprakhar wrote: post #3

> In some cases, for pure data validation and processing, you can get performance improvements of 20x or more. This means 2,000% or more. Amazing! Excited to try it out. Slightly OT: But what are some use-cases where you'd still use Flask over FastAPI? I really like FastAPI's devEx and don't see myself going back to Flask anytime soon. Curious to hear what others think.

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?

Re: FastAPI 0.100.0 release notes

#86

Post by andrewstuart »

miiiiiike wrote: post #68

I wish Django would take async more seriously. This comment gives a pretty good overview of the current situation (some points are more valid than others): https://github.com/encode/django-rest-framework/discussions/... The Python ecosystem is strange. Where other dev communities will embrace new ways of doing things faster than most people can keep up — the Python community needs to be pulled kicking and screaming i…

Have a look at Starlette, it’s by the guy who made Django.

FastAPI is built on Starlette and adds more batteries included.

If you’re interested in async you’re far better off to go async native than with a framework that’s synchronous.

Asyncpg is the fastest Python Postgres driver there is, works well with sanic, Starlette or FastAPI.

Re: FastAPI 0.100.0 release notes

#87

Post by delijati »

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

Re: FastAPI 0.100.0 release notes

#88

Post by delijati »

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

just looked into the docs [1] and indeed it has CBV ... I will definitely take a closer look.

[1] https://docs.litestar.dev/latest/#feature-comparison-with-si...

Re: FastAPI 0.100.0 release notes

#89

Post by senko »

rewmie wrote: post #82
senko wrote: post #11

Earlier quoted context omitted.

This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ )

> This is semver: This is a good example of people confusing the letter of the law with the spirit of the law. Semver is not a goal onto itself. Semver expresses a process to help consumers of an interface infer the implications of an upgrade without having any context on what specifics went into a release. Major changes imply breaking changes, minor changes imply addition of backward compatible changes which can pre…

> Semver is the tool, not the cause.

> If product maintainers do not care about stable versions, it makes no difference if they comply with semver or not.

Exactly. Here, the maintainer reserves the freedom to break anything at any moment, and correctly uses semver to signal that through version number.

(Not) using semver as a versioning scheme is orthogonal to whether an API is stable.

As a potential user of said package, seeing this (among other things), I choose to use another package (Django REST Framework) whose maintainers do care about not beeaking the API.

Re: FastAPI 0.100.0 release notes

#90

Post by Aeolun »

TheRealPomax wrote: post #65
senko wrote: post #11

Earlier quoted context omitted.

This is semver: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (from https://semver.org/ )

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?
Post reply on HN