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

61–70 of 115 posts

Re: FastAPI 0.100.0 release notes

#61

Post by TheRealPomax »

the__alchemist wrote: post #23
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…

FastAPI doesn't use Semver; it uses ZeroVer: https://0ver.org/

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

Re: FastAPI 0.100.0 release notes

#62

Post by aliasxneo »

palata wrote: post #44
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…

Because it seems like devs believe that 1.0.0 means "the API is perfect, it won't break ever again". 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.

Just had this conversation the other day. It's become so unusual to see high major versions that it's basically become taboo.

Re: FastAPI 0.100.0 release notes

#63

Post by TheRealPomax »

eyelidlessness wrote: post #45
eyelidlessness wrote: post #43

Earlier quoted context omitted.

This is using semver in the exact way it’s intended but with predictably silly outcomes. For several years now I’ve been of the opinion that this particular aspect of semver is … very bad actually. 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.

And to clarify the approach, the equivalent version would be 1.0.0-alpha.100.0. Clear in its meaning, clear in versioning resolution, ambiguous only in its maturity but that’s what the project is trying to do. Edit: or probably it’s 1.0.0-beta.100.0. That’s still much clearer

Not if they've dropped support for several versions of Python over the years, no. More like v5.10.12

This software is absolutely not in alpha anymore, it's used in production and the project even acknowledges this explicitly.

Re: FastAPI 0.100.0 release notes

#65

Post by TheRealPomax »

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/ )

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.

Re: FastAPI 0.100.0 release notes

#66

Post by norgie »

palata wrote: post #47
foolswisdom wrote: post #20

Earlier quoted context omitted.

FWIW other frameworks (namely, flask) took a similar approach of not moving to 1.0 for a while.

Which sucks, to be honest. Just accept that your major can go up to 23.8.3, and it does not make it less professional than 0.231.0. Actually it's better because it said which releases broke backward compatibility and which ones did not.

Seriously, this 0ver nonsense makes it so much harder to deal with upgrading packages. Who cares you bump the major version frequently

Re: FastAPI 0.100.0 release notes

#67

Post by Zababa »

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/ )

From the same link:

> 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.

Re: FastAPI 0.100.0 release notes

#68

Post by miiiiiike »

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 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.

Re: FastAPI 0.100.0 release notes

#69

Post by monlockandkey »

My only frustration with fastapi is the lack of API documentation.

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

Re: FastAPI 0.100.0 release notes

#70

Post by arun-mani-j »

gsa wrote: post #12
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.

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 wa…

Exactly my issue too. Why there is no API documentation for FastAPI? It is very difficult to know what is available and what is not beyond the tutorial style docs.

(I love FastAPI and use it for all my projects, this one little thing troubles me sometimes)

Post reply on HN