[HN Gopher] FastAPI 0.100.0 release notes
___________________________________________________________________
FastAPI 0.100.0 release notes
Author : constantinum
Score : 51 points
Date : 2023-07-07 17:49 UTC (5 hours ago)
(HTM) web link (fastapi.tiangolo.com)
(TXT) w3m dump (fastapi.tiangolo.com)
| TheRealPomax wrote:
| > 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 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.
|
| [1] https://fastapi.tiangolo.com/deployment/versions/
| nerdponx wrote:
| Semver specifically allows you to use 0.x for this purpose:
| https://semver.org/#spec-item-4
|
| > 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.
| [deleted]
| senko wrote:
| 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/)
| foob wrote:
| Sure, depending on how you interpret _initial development_.
| FastAPI has 60k stars on GitHub, has been extremely popular
| for at least four years, and is widely used in production by
| a lot of people. It 's the maintainers' decision what their
| goals are for a v1 release, but I was personally surprised to
| learn that it hasn't had one yet. I can see why one might
| argue that they're not following the spirit of semver at this
| point.
| capableweb wrote:
| As long as the developers/maintainers feel like "Anything
| MAY change at any time" and "The public API SHOULD NOT be
| considered stable" is true, both the "spirit" and
| specification (if we may call it so) say it should be on
| 0.x.z
| the__alchemist wrote:
| FastAPI doesn't use Semver; it uses ZeroVer: https://0ver.org/
| foolswisdom wrote:
| FWIW other frameworks (namely, flask) took a similar approach
| of not moving to 1.0 for a while.
| aliljet wrote:
| I'm really curious about why you would want to use FastAPI over
| Django Rest Framework. Are there signficant advantages to
| FastAPI?
| djaychela wrote:
| I've just made a first project in fastAPI, and it was trivially
| simple compared to my previous adventures in DRF. Plus asyc
| from the get go, which was also pleasant. I had a task as part
| of this that takes 10 seconds to run, and there's a built in
| way to allow it to run in the background.
|
| And the documentation is excellent.
| The_Hoff wrote:
| FastAPI is a joy to use. Tried using `bump-pydantic` and it
| worked flawlessly. Thankful for the work by this team.
| svaha1728 wrote:
| Did not take long at all to see Pydantic version 2 support. Nice!
| nerdponx wrote:
| I still can't stand Pydantic's API and its approach to non-
| documentation. I respect the tremendous amount of hard work
| that goes into it, but fundamentally I don't like the developer
| experience and I don't think I'll ever feel otherwise. I use it
| because my coworkers like it and I've learned its advanced
| features because I had to in order to get things done, not
| because I like it.
|
| 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.
| willhoyle wrote:
| I too have made similar observations regarding pydantic and
| FastAPI.
|
| 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.
| nikcub wrote:
| 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.
| Kydlaw wrote:
| 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.
| krat0sprakhar wrote:
| > 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.
| aardshark wrote:
| Not to be excessively negative, but this really means very
| little without more context. Maybe it was very slow before, or
| it's a particulary unused scenario. I'm always skeptical when
| people write such praises of their own software without giving
| a comparison point.
| agent281 wrote:
| 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.
| WhatsName wrote:
| Coming from django primarily, but written some flask code. I
| would say the ecosystem. As of my last try, adding
| authentication (via cookies) to a fastapi project was somewhat
| cumbersome.
|
| Usually as the projects grow, and I start reinventing the
| wheel, I come to regret not going for a "full" framework.
| 0cf8612b2e1e wrote:
| Is it still a bus factor of one? I veer to the side of boring
| technology and FastAPI is still too in flux for me. I do not
| ever want to be the vanguard discovering novel problems with my
| framework.
| nerdponx wrote:
| Definitely this. Flask is old and well-tested, with a solid
| feature set and little need to change how it works.
|
| 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.
| gsa wrote:
| Flask has been around much longer than FastAPI and, as a
| result, is a much more mature framework. Some examples:
|
| - 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...
|
| - [3] https://github.com/encode/uvicorn/issues/527
| minimaxir wrote:
| > - You need ORJSON for maximum serialisation performance
| (perhaps this has changed with Pydantic v2) [2]
|
| 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.
___________________________________________________________________
(page generated 2023-07-07 23:01 UTC)