FastAPI 0.100.0 release notes
fastapi.tiangolo.com
fastapi.tiangolo.com
What kind of weird reasoning is this? This should be why you use actual semver, and you use the major version to indicate backward compatibility breaking changes, minor versions for new features, and patch versions for bug fixes that don't actually actually change the public API surface.
If you don't want to use semver, just don't use 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.
That said, I'd argue that this is a little silly. Maybe a better design is to use something I am calling "zero-calver": 0.YYYY.MM.DD. Then use semantic versioning once stability is reached.
Then maybe it goes up to 41.x.x until stability is reached. So what? It's not less professional than keeping 0.x.x forever.
> 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/)
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.
> How do I know when to release 1.0.0?
> If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.
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.
> 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.
There've been plenty of projects that officially use 0.x versioning for years now.
.
.
.
Your head
Sarcasm isn’t funny to everyone; GP was understandably confused. This isn’t Reddit.
Do try to catch up.
It's a tendency of developers to make things complex.
Changing the major means that it breaks backward compatibility. Changing the minor means that it has new features. Changing the patch means that it had bugfixes.
That's useful for libraries. Of course it's a bit less useful for executables. I just increase the major for executables, but if I need to backport a feature or a fix (to somebody who still uses an older version), then I use the minor/patch.
For personal projects I skip any zero major prefixes. In their place, I use alpha/beta suffixes and version Major/minor/patch from an initial 1.0 alpha. Hasn’t caused any problems for me.
Edit: or probably it’s 1.0.0-beta.100.0. That’s still much clearer
This software is absolutely not in alpha anymore, it's used in production and the project even acknowledges this explicitly.
Somehow they feel like having a version 15.2.3 looks unprofessional (because the API got broken 14 times), but 0.100.0 is perfectly fine.
I just don't get it.
Semver explicitly encourages you to use major version 0 during early development for this exact reason, it's up to the maintainers to decide when they can be more stable.
https://dev.to/v3ss0n/litestar-20-beta-speed-of-light-power-...
Starlette can be considered pure server framework in the lines of CherryPy, wezurg in wsgi/sync world.
Litestar is a lot more battery included with built-in integration to Sqalchemy, many other ORMs as plugin. Built-in security and authentication middleware.
Join our discord, we have good community there too .
Starlette and Litestar are very different. Starlette is closer to Flask or actually Werkzeug; A micro framework / toolkit for building apps.
While we don’t aim to develop "The next Django", Litestar offers way more out of the box than Starlette and other micro frameworks.
[1] https://github.com/KiraPC/fastapi-router-controller [2] https://github.com/tiangolo/fastapi/issues/617
[1] https://docs.litestar.dev/latest/#feature-comparison-with-si...
app = Litestar(on_startup=[get_db_connection], on_shutdown=[close_db_connection])
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
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.
Also you'd use Flask for basically anything that isn't an "API", but where you still want something lighter-weight than Django. I believe other traditional Python web frameworks like Pyramid fall into the same category.
The "Fast" in FastAPI refers to the speed of getting a working prototype running, specifically for an API that accepts and emits JSON and implements an OpenAPI schema. If that's not your use case, then you might not need or want FastAPI.
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
That is at least partly the case. I maintain msgspec[1], another Python JSON validation library. Pydantic V1 was ~100x slower at encoding/decoding/validating JSON than msgspec, which was more a testament to Pydantic's performance issues than msgspec's speed. Pydantic V2 is definitely faster than V1, but it's still ~10x slower than msgspec, and up to 2x slower than other pure-python implementations like mashumaro.
Recent benchmark here: https://gist.github.com/jcrist/d62f450594164d284fbea957fd48b...
Eeh come on, I think it's a bit unfair to compare, because msgspec doesn't support regular python union types… which are the number 1 source of slowness… at least in my real world use case of the thing. I've got hundreds of classes with abundant nesting and unions.
In pydantic v2 they did the same thing i've been doing in typedload for a few versions already: check the field annotated with a Literal and directly pick the correct type, rather than do try and error. So now the speed for unions has become better.
Even so, for being binary vs pure python, I'd have expected much more.
I maintain typedload (a similar project, that I started before pydantic's first release) and pydantic 2 somehow still manages to be slower than a pure python library that got no funding to improve performances.
Usually as the projects grow, and I start reinventing the wheel, I come to regret not going for a "full" framework.
- There's a memory leak with a particular combination of packages FastAPI [0]
- Before Pydantic v2, you would validate your data on input (when it's stored in the db) and then every single time on retrieval. There is no way to skip validation, for example, when you are generating a response on data that was already validated when it was persisted to the db. [1]
- FastAPI has documentation only in the form of tutorials. There is no API documentation and if something is not clear looking through the source code is the only option
- You need ORJSON for maximum serialisation performance (perhaps this has changed with Pydantic v2) [2]
- Using FastAPI with uvicorn doesn't respect log format settings [3]
I don't mean to imply that FastAPI is a bad framework. The Flask ecosystem has had over a decade to mature. FastAPI and the ecosystem will get there but it _needs_ time.
- [0] https://github.com/tiangolo/fastapi/discussions/9082
- [1] https://github.com/pydantic/pydantic/issues/1212
- [2] https://fastapi.tiangolo.com/advanced/custom-response/#use-o...
The common orjson trick no longer works in v2 and will throw warnings, but it appears it's no longer necessary since the JSON formatting leverages the native seralizer which happens in Rust-land.
(I love FastAPI and use it for all my projects, this one little thing troubles me sometimes)
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 author will refuse to benchmark any library that is faster (https://github.com/pydantic/pydantic/pull/3264 https://github.com/pydantic/pydantic/pull/1525 https://github.com/pydantic/pydantic/pull/1810) and keep boasting about amazing performances.
On pypy, v2 beta was really really really slow.
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?
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)
So much for your invite to be gentle and cooperative :D (https://github.com/ltworf/typedload/pull/422)
Anyway no server code runs on apple, so it isn't that important to win benchmarks only on apple, I think.
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 into the light once ever decade or so. Python 2 to 3, ~10 years.
async/await has been in Python since 2015, it feels like it's going to be another 5 years before we see people taking async seriously in the big packages. Same problem we had during the 2/3 transition. No library support, no developer support.
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.
I’ve been keeping an eye on FastAPI, Starlette, and a few other libraries but, compared to Django, they’re mostly powered by hype. I found a bunch of Pydantic bugs 2(3?)+ years ago that are only now getting addressed in v2.
CRUD , Filtering , Pagination , and many common apis by default . Those need Extension in django.
For CRUD : https://github.com/litestar-org/litestar-pg-redis-docker/
For fullstack experience see : https://github.com/cofin/litestar-fullstack - it has Users and Auth , Roles , Teams , Tagging , Data migration , Caching , Background Worker Services , Background scheduling , manage.py-like cli for creating users , admin users , and docker containers.
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.
Also Please give litestar a try.
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.
That's exactly what a container is for.
Container is just a logical isolation tool that works at the distribution/deployment level.
Back in 2008 , We ship by DDing the whole disk :D
Containers add huge complexity, for what?
However, at least for me containers solves 3 main source of problems to shipping code in a current software environment: (1) somewhat consistency around runtime environment between production, development and homologation (2) a portable way to deliver software (just create the image) and (3) packaging between source code and runtime.
I started my career at the late-2000s and at least in my experience the code itself was the least of issues because we needed to develop something in a environment to be delivered at a runtime in another, transfer the files via FTP or replace files with _.old and making sure that it would work in all places.
We had use nodejs/ts , but nothing meets DX of python , or Python + MyPy yet, and ecosystem is unmatched.
And the documentation is excellent.
My experience has been, as Seth Godin says, “the long-cut is the most direct route to get to where you seek to go”
Every time I started with Django, I hated the feeling of sitting in boilerplate hell early on.
Every time I started with FastAPI/Flask, I get something working quickly, then hit a wall of recreating everything that comes with Django.
The only solution I’ve found is: embrace boilerplate [1], automate the boilerplate.
[1] Django, or whatever batteries included framework you like (Rails, Laravel, Phoenix, etc)
FastAPI is much closer to Flask in that it's trivial to throw up a single file with a couple of routes, and you can use something like SQLite yourself for persistence to disk, or install a couple of libraries for authentication or such (not sure if that's built in by now).
Django, on the other hand, requires a multi-step process to even start a project and creates a dozen of files, most of which are boilerplate, before you can even see a "hello world" route.
But in exchange, you get not just a program which deals with routing and templates and status codes, but much more - a world-class ORM which integrates pretty much transparently with multiple data stores like Postgres or SQLite, an amazing dashboard out of the box which is really handy for sharing with non-techies, a very mature ecosystem, and perhaps most importantly, the "one right way to do things", which makes it a lot more effective for collaboration between a bunch of engineers. It's of course not infallible, has a learning curve, and comes with a good few footguns that get the uninitiated, but the upside is a real upside. Migrations alone might justify it - for all the grief of merge conflicts between migrations right before a code freeze, I can't imagine how much worse it would be to not have them.
So I wouldn't say there's significant advantages to using either - they're different tools for different use cases. If you want to get something up quick that isn't too complex, FastAPI is great for that. If you know you're eventually going to rewrite Django but worse, you may as well use the real thing.
All from a few lines of code.
But I've mostly switched to django-ninja which is more type safe and faster.
[0] has replaced pylint, flake8, pyupgrade, isort, mccabe and pydocstyle
[1] bump-pydantic worked well, after porting settings to pydantic_settings.
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.
Edit: Scratch that, had a go now with no trouble, passing `pylyzer --server` from my editor (helix).
It used to have literally thousands of open issues. Where did they go? Fixed?
It also had a project owner who refused to form a team of people responsible for the project. How did that pan out?
I would love to see a FastAPI alternative still using Starlette internally, but using Attrs + Marshmallow + Cattrs + Apispec instead of Pydantic. It would be a little less "fast" to write a working prototype, but I'd feel much more comfortable working with those APIs, as well as much more comfortable that my dependencies are well-supported and stable.
The problem of course is not that gluing those things together is hard. The problem is that now someone has put untold hundreds of person-hours into FastAPI, and replicating that level of care, polish, bugfixes, feature requests, etc. is difficult without putting in those hundreds of person-hours yourself.
I was evaluating various Python async http frameworks and landed on a similar stack:
- attrs/cattrs for models - starlette+uvicorn for HTTP/websocket - validation I’m still on the fence about. I’ll see how far I get with the built in validators offered by attrs. I use voluptuous at work and generally like the DX but it’s in maintenance mode.
This is purely personally preference, I’m sure devs using fastapi+pydantic are more productive in the long run. It almost feels like I’m hand rolling my own fastapi implementation but at the same time I don’t want to be too locked in to frameworks like that.
Ive been burnt by magic frameworks that do too much behind the scenes and there’s something nice about fully understanding what’s going on when you hand stitch libraries yourself.
It works out-of-the-box with attrs objects (as well as its own faster `Struct` types), while being ~10-15x faster than cattrs for encoding/decoding/validating JSON. The hope is it's easy to integrate msgspec with other tools (like attrs!) rather than forcing the user to rewrite code to fit the new validation/serialization framework. It may not fit every use case, but if msgspec works for you it should be generally an order-of-magnitude faster than other Python options.
[1]: https://github.com/jcrist/msgspec
</blatant-evangelism>
> {Litestar|Starlite} is a powerful, flexible, highly performant, and opinionated ASGI framework, offering first class typing support and a full Pydantic integration. > > The {Litestar|Starlite} framework supports Plugins, ships with dependency injection, security primitives, OpenAPI schema generation, MessagePack, middlewares, and much more.
For many of us especially in the SaaS side, speed of these operations is a distant third priority compared to ease of writing and understanding the code, and ensuring reliable less buggy code. The actual compute happens on a cluster with spark or snowflake anyway.
The API is a little weird, particularly around defining validators. The parameter name-matching is an "interesting" design choice. Accessing "values" as a dict[str,Any] is messy if you care about static typing, although I can understand why they did it.
Furthermore, the behavior of validators and the exact sequence in which they run is not defined by the docs. It's not that hard to figure out, but it also might change at any time because there's no user contract. Attrs is significantly nicer in just about all respects here, especially their attention to detail in their extensive user guide and reference docs.
Speaking of user contract, there's no clear separation between private and public. Without a reference doc it all looks like fair game, but without a reference doc it also might all change at any moment. Either you stick to the examples, or you're off doing a guess-and-check dance and hoping something doesn't break.
Even with the Mypy plugin, I often have to write `if TYPE_CHECKING` all over any nontrivial Pydantic class consuming data from external sources. Variable annotations in Pydantic are fundamentally not PEP 484 type hints. That's fine, but it's confusing that they're almost the same, and, as above, it's almost entirely up to you to figure out how it all works, either by trial and error or by digging around in the issue tracker and StackOverflow.
Ease of writing and reliability is precisely my big area of annoyance and concern. Speed of (de)serialization is comparatively unimportant (although I don't like the huge amount of overhead involved and I avoid using it in hot code paths).
I also don't like using Pydantic-defined classes very much, because the actual init method signature is just *args, **kwargs, which doesn't work well with any tooling. It feels like being back in the Tornado & PyMongo dark ages where everything is dynamic or dynamically-generated and classes are just glorified hash tables.
I agree that the JSONSchema integration is outstanding. BaseSettings is also a tremendous productivity improvement, I love that I can define a class and immediately get a proper app-wide config reading from both env vars and a dotenv file. I also like the default error messages that tell you exactly which field failed validation. I also like the validator system (once I figured out how it worked), respecting the order in which I define the validators as well as supporting validators that run before or after the default set of validators (pre=True and pre=False respectively). I was probably being a little too negative before, but my annoyance level with the developer-facing API and documentation remains high, and I will gladly jump to an Attrs-based alternative as soon as one exists.*
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/
Usually docs just have API specified, this project goes the other end of the spectrum and has examples for everything.
Whilst that is nice, APIs are undocumented and it is a bit harder to grok the project without the available functions and methods in a list