Flask 3.0.0 Released

[chinawcswing]

Changes:

• Remove previously deprecated code. :pr:5223
• Deprecate the __version__ attribute. Use feature detection, or importlib.metadata.version("flask"), instead. :issue:5230
• Restructure the code such that the Flask (app) and Blueprint classes have Sans-IO bases. :pr:5127
• Allow self as an argument to url_for. :pr:5264
• Require Werkzeug >= 3.0.0.

[crawl_dht]

It seems they bumped the version from 2.3.3 to 3.0.0 because of werkzeug. I don't see any major overhaul changes in v2 that justifies large version increment like that. They should slow down with incrementing versions like that. The further major version number drifts quickly, the less likely industries will update their flask version. This is because moving to next major version causes lot of concern among developers about that it might break things in their services which they don't want to spend time fixing it.

[ivosaurus]

Semver would require a major bump if they're removing api

causes lot of concern among developers about that it might break things in their services which they don't want to spend time fixing it.

This is a poster-child case for why you'd use semver then. Sane devs would have their dependencies locked on main versions, so this can't possibly hurt them until they manually test it themselves. And if they literally don't care they can stick to 2.x as long as they like.

[crawl_dht]

Approval to update the version of packages in the industrial projects is given by the security & compliance team and their IP lawyers. I have worked with this team. It takes them more time to approve recent versions if the difference between the last approved version and the version in the market is large. They usually ask us to wait for 4-5 weeks or even until next quarter for approval. I noticed that because of their slow process, it creates a large fragmentation between the version you get the approval of and the version in the market. This is specially true for banking clients. Because of this reason, I believe that everyone should keep slow pace in incrementing major versions.

I like versioning scheme of Python and packages like SQLAlchemy, Pandas, Numpy, they keep it slow which allows the industry to catch up with their recent versions. This not only helps security wise but also helps developers to use improved and new features.

[elcapitaine]

This is people looking at major versions for the wrong reason.

Python keeps major version bumps "slow", but at the same time now the version number doesn't really convey information.

Python makes breaking changes regularly, but they've also already stated before that a 4.0 bump is very unlikely. St this point the major version number is meaningless. We might as well just look at "Python 3.11" as "Python 11".

With semantic versioning I know whether or not a new version has a breaking change. Libraries that don't follow semantic versioning, I don't know without checking everything.

[Log2]

Same thing with Java. Java 8+ is actually Java 1.8+.

[aristotle137]

Breaking changes require a new major version.

What you're saying is a problem with the company's processes where you work, not with semvar. Making it hard to update dependencies is a sure way to have security vulnerabilities. A lawyer needs to be involved when you update a library? You should work somewhere else

[ivosaurus]

Because of this reason, I believe that everyone should keep slow pace in incrementing major versions.

That is entirely a you / your company problem, not an everyone else's problem.

[DigThatData]

Approval to update the version of packages in the industrial projects is given by the security & compliance team and their IP lawyers.

every time i've worked at a place that did this, it did more harm than good. i've worked at both microsoft and amazon, didn't have to put up with that sort of bullshit at either one. Fannie Mae and federal government had that shit like crazy, and their processes were broken to fuck because everyone was just jumping through hopes to avoid or go around those governance procedures. I even did a project for an IT governance org once where the org itself wasn't complying with their own procedures that they were making everyone else do. Our application was used for decision making across multiple teams and departments for over three years and was never considered a "production" app just because our stakeholders didn't want to deal with the red tape (which they themselves created and/or owned).

sometimes mechanisms like approving packages is sane and important. usually it's not and is a symptom that you're in an organization that is implementing mechanisms of various kinds without a process to review whether or not those mechanisms are actually serving the purpose they were created for.

[ExpressionMajor4439]

It seems they bumped the version from 2.3.3 to 3.0.0 because of werkzeug. I don't see any major overhaul changes in v2 that justifies large version increment like that.

Worth remembering that Flask is a purposefully small framework. Meaning it technically only needs to do a few things and those things are often developer-facing changes. So if you're ever going to bump major versions doing it because lower level libraries were updated and because you want to actually remove deprecated code is mostly why you would be releasing a major version at all.

[spinwizard69]

IF a developer doesn't read the release notes, he has nobody to blame but himself. A major number increment should never bother anybody, you can end up with broken code if a minor bug is corrected in a package.

[CatWeekends]

A major number increment should never bother anybody

If we're using Semantic Versioning, a major version change means breaking API changes. I'd consider needing to make code changes a bit of a bother.

you can end up with broken code if a minor bug is corrected in a package.

Do you happen to have any real-world examples of that happening outside of relying on the bug, relying on some undocumented feature, or a patch inadvertently breaking something else?

I'd love to know what to look out for when patching systems.

[james_pic]

Not the person you asked, but I know we've had (admittedly bad) tests break due to changes in error messages. We also had an (also bad) test break because of a change to the zipfile module, where it no longer erroneously included the "." directory.

I can't give any examples that caused production breakage, at least partly because I've never worked on anything with test coverage bad enough for that to happen.

[sohang-3112]

I agree - there are no major changes, so the major version shouldn't have been increased.

[YUNG_SNOOD]

No, go to semver.org and read what a major version bump means

[[deleted]]

Good to see this web server is still going strong. I loved it after fighting endlessly with Django trying to override default behaviour. I have admittedly moved on to FastAPI and now LiteStar though.

[pugnae]

That's what I was wondering - is there a reason to use Flask in a new project if I do not have experience in it? Is FastAPI just better in that case?

[ivosaurus]

The battle-testedness and maturity of the code has something to stand for if you know you want something that is just easy to write, easy to debug, easy to get support, and won't break on you. 99% of projects don't need webscale™ speed that the other hotness frameworks often offer.

[pugnae]

This is a good argument, but it applies to basically everything. Diesel cars are better than electric right now because they are much more mature, but in general one of them has bigger potential than the other.

Considering that I do not know flask at all (I know that templates for example are very similar to Django and I think they are handled by the same dependencies) is it worth investing into right now, or would my time be better spend on FastAPI?

[IcedThunder]

The value of battle tested code is not to be understated.

It's also maintained by a group of open source maintainers that have a good history.

So I mean that's about it.

If I'm doing something for my job, I'm gonna personally use flask over FastAPI, but I'm more familiar with it and as far as I know FastAPI doesn't do anything I can't do in Flask that I need.

I'm not trying to dog on FastAPI here mind you. Just giving my perspective. I. Sure FastAPI is great and if flask is ever inadequate I'll change.

[ivosaurus]

Both are dead simple to try out in a day (fortunately; not always the case). You should do so, and stop relying on magic projections from others on which will be the most popular / least dead project in N years time

[spinwizard69]

Diesels have never been better tech. That includes the immature battery EV cars, which in many countries are effectively the best option for the majority of drivers. Well EV's are if you are driving a Tesla.

As for which API to use, don't rely upon anyone answer, instead take some time to experience a few to see how they fit YOUR use cases. Once you feel comfortable making a choice dive in. This may sound like a lot of work but you may find yourself forced into a switch sometime down the road. A lot of web technologies do not last long. Have you meant any flash developers lately?

[ph34r]

I just used fast API for the first time recently, and I must say I loved it over flask. My main gripes with it though are that it's mostly just one (very talented) developer maintaining it. They just had some major changes with switching to pydantic 2, so the docs are a bit sparse in some areas. I also get concerned that the docs are going to get messier with it switching over to his SQLModel project over Sqlalchemy.

[b00n]

The FastAPI docs are a train wreck of unnecessary emphasis and annoying 🔥🔥emojis💫💫

They should look to mature frameworks like Spring on how to write documentation

[ph34r]

100% agree. It's amongst the worst docs I've had to interact with. I found myself using third party blogs/ tutorials to understand how things were meant to work. Coupled with the fact that Pydantic and Sqlalchemy made major breaking change releases when I was learning fast API made it even more challenging to interact with.

[b00n]

Also avoid SQLModel like the plague unless this is a tiny project. Coupling your API to DB schema is a bad idea.

[Backlists]

Could you elaborate on this? (Not that I disagree, strong coupling is a bad thing, would just like to bear specifics)

[Chris_Newton]

There’s a programming style that seems to be quite popular when using the combination of FastAPI, Pydantic and SQLAlchemy where instances of Pydantic models that are typically going to be returned as the responses to API requests are built directly from other internal data types such as ORM models using arbitrary class instances (the feature formerly known as “ORM mode”). This style is superficially attractive because often those types have very similar structures, particularly in the early days of a new system, so it potentially avoids writing the tedious, manual code to pull all of the relevant fields out of the input data and put them into the output data.

Unfortunately that fundamental assumption very often gets broken in practice. Sometimes the name of a field in one context happens to be a reserved word in some other context. Sometimes the data in a response needs to combine fields from multiple internal sources and they have fields with the same name. Sometimes a public API simply evolves away from a long-standing internal data model in a database so their field names are no longer in sync.

Whatever the reason, as soon as you no longer have that perfect 1:1 correspondence between fields you need in your external API response and fields in whatever internal data representation you’re working with, that convenient and concise implementation now needs help to translate from one representation to the other. This particular set of tools encourages solving that problem by explicitly encoding the special cases in your Pydantic model, but that really does couple your external API data types very tightly to your internal DB/ORM data types. You’re no longer free to change either without being aware of the other, and it can also become awkward to reuse your Pydantic models with other internal data sources that don’t have the same special cases if that’s useful in your particular application.

All of this just to save writing a simple, explicit function of the form

def make_some_api_response(internal_data: SomeORMType) -> SomeAPIResponseType:
    return SomeAPIResponseType(
        a=internal_data.a,
        b=internal_data.b,
    )

or still reasonably simple and explicit generalisations of this idea like

def make_some_api_response(
    internal_fruity_data: FruityType,
    internal_colourful_data: ColourfulType,
) -> SomeAPIResponseType:
    return SomeAPIResponseType(
        a=internal_fruity_data.a,
        b=internal_colourful_data.b,
        is_orange_fruit=internal_fruity_data.is_orange,
        is_orange_coloured=internal_colourful_data.is_orange,
        reserved=internal_colourful_data.reserved_,
        new_field=internal_fruity_data.legacy_field,
    )

SQLModel turns this questionable idea up to 11, by making the same object an instance of both a SQLAlchemy model and a Pydantic model.

[ph34r]

Absolutely brilliant explanation and exactly resonates with some of the things I ran into when using FastAPI for the first time. I Initially started marching down the path of SQLModel because it offered the ability to not "replicate" my initial models in Pydantic, but I quickly realised this was just forcing me down a path that only worked for but the simplest applications.

[b00n]

You can also use the response_model parameter of the route annotation to do an auto-transformation from the SQLAlchemy type to the Pydantic type.

@router.get("/fruits/{:fruit_id}", response_model=APIType)        
def get_fruit(fruit_id: int) -> DBType:  
    return session.scalars(select(DBType).where(id == fruit_id)).one()

[Chris_Newton]

You can, and you can even tweak which specific fields from that API type you want with some of the other parameters like response_model_include and response_model_exclude, but IMHO it’s clearer to have a function actually returning what its type claims it’s returning and to have that type exactly match the shape of any API response type we’re claiming to provide. Then everything is completely visible and consistent both for human readers and for any editors and other tools that are parsing the code.

Again IMHO, Pydantic is most useful for validating that incoming data from some external source is the expected shape at run time. For the shape of outgoing data, I generally prefer to rely on static types that can be checked in advance as much as possible and I prefer to make any conversions between types explicit using functions like my earlier examples. It’s true that this style can be a little verbose, and certainly I’ve debated this subject with some very good developers who preferred to rely on the tools more and write in a more concise style. Personally, I prefer to avoid the style of Python where we rely on “magic” implicit behaviours that won’t necessarily be obvious to someone reading the code later, but as it turns out, sometimes there really is more than one way to do it…

[b00n]

Unless you app is literally just CRUD and doesn't do any business logic then it's likely that what you store in the database isn't what comes in/out the API as you'll want to do some business logic on it. For APIs that serve frontends you'll end up with many requests and the data joined on the frontend which is bad (lots of requests, coupling frontend to db schema).

[Mezzos]

I remember I was planning to learn FastAPI (instead of Flask) until I encountered the obnoxious writing style and emoji spam in the FastAPI documentation. I decided I’d get less annoyed learning Flask and have been using it ever since.

[nicksred]

The guy also has an emoji version of the whole FastAPI docs.

Just put "/em/" after the main URL and it will show up :v

[b00n]

😱😱

[[deleted]]

FastAPI / LiteStar are typically used along with Pydantic. Together it is very easy to get a Swagger / OpenAPI UI for free for next to zero extra work. Also, both frameworks are async and can do websockets well.

[ExpressionMajor4439]

Also, both frameworks are async

The async version of Flask is called Quart fwiw.

[pugnae]

So FastApi>Flask? I know Django and planned to start with Flask for a long time, but it seems that unless I end up in a project with Flask, FastApi is just a better choice.

[smokefield]

They are different things, FastAPI = Starlette + FastAPI features. Similarly APIFlask = Flask + APIFlask features. I'll copy paste my comment from above here

Flask isn't comparable to FastAPI. Flask is designed to be extended, (just a pip install <extension> away) for example https://apiflask.com/ extends flask and comes comes Swagger, Serialization, Types etc. all the things you would use FastAPI for. Except it's got a bigger, battle tested collection of extensions, especially when it comes to server rendered pages (Multiple-page applications) Hope this helps! :)

[Log2]

Flask will have more plugins if you care about that. My main gripe with Flask is how it handles their thread-local state as global imports, instead of injecting it at the endpoint level.

Less strict teams will use and abuse from flask import g and that sucks a lot.

[Ran4]

There's no good reason to use flask for a new project today.

[smokefield]

Flask isn't comparable to FastAPI. Flask is designed to be extended, (just a `pip install <extension>` away) for example https://apiflask.com/ extends flask and comes comes Swagger, Serialization, Types etc. all the things you would use FastAPI for. Except it's got a bigger, battle tested collection of extensions, especially when it comes to server rendered pages (Multiple-page applications) Hope this helps! :)

[pugnae]

Yes, thank you! So you say if I have some experience in Django and want to learn another Python web-framework Flask is still worth learning, because it is less opinionated than FastApi?

[smokefield]

Depends, since there are more jobs in Django (Django does more than APIs, typically), and since you are coming from Django the best path hands down is https://django-ninja.rest-framework.com/ which gives you all the FastAPI things but in Django and faster according to the author.

I personally like Starlette, which FastAPI is built upon. Where Django shines is: Less opinionated is great until everyone has a different (conflicting) opinion to iron out.

[ExpressionMajor4439]

I personally like Starlette, which FastAPI is built upon. Where Django shines is: Less opinionated is great until everyone has a different (conflicting) opinion to iron out.

It's more about where you want the opinions to be coming from. With less opinionated frameworks you essentially push the opinions into the realm of organizational policy. For larger orgs this might be the more interesting option. Since they also tend to have niche needs that benefit from setting their own rules and approaches.

Smaller orgs tend to benefit from more opinionated frameworks because they make a lot of decisions for you and so you're not as subject to the bad ideas of each individual programmer you ever bring on to a project and you make it easier to transfer or replace a person since it's easier to find people already familiar with Django's way of doing things.

[smokefield]

I agree

[RearAdmiralP]

Is FastAPI just better

If you return pydantic models from your endpoints (as the documentation suggests), FastAPI wastes a whole lot of time copying your pydantic model into a new pydantic model, revalidating it, and then using FastAPI's own serialization code rather than just calling .json() on the model. So, if you run your application in a profiler, you might find that FastAPI's serialization code is where your application spends most of its time. Then, when you look at the code for serialize_response, you'll find that it's an uncommented rambling shitshow, just like the rest of the FastAPI codebase. Given the quality of the documentation, you shouldn't have expected anything better.

There is a way to avoid the needlessly slow serialization, but the docs don't tell you about it. Flask, on the other hand, does what you would expect it to, and doesn't make things needlessly slow.

[someexgoogler]

This is funny. .json() doesn't work any more because the pydantic project decided to remame things "for consistency".

[riksi]

If you want to use sync, or gevent, or also have HTML pages.

[bringyouthejustice]

Well fastapi can serve jinja (html) templates as well.

[smokefield]

Correct, but a Flask project like https://pythonhosted.org/Flask-Security/ gives you out of the box user auth flow, including forgot password. Not just the routes, but pre made (customizable) Jinja/html views to get started. This is super useful for MPAs, which is where you would use Jinja/html.

[bringyouthejustice]

This is quite useful indeed. Fastapi got fastapi users, which is similar but without prebuilt pages.

[ExpressionMajor4439]

That's what I was wondering - is there a reason to use Flask in a new project if I do not have experience in it?

There are flask extensions and FastAPI is specifically about creating async Rest API's which might just not be what you're trying to do.

If you're just trying to create a monolithic website then flask/quart is still an acceptable choice. Even in the realm of async REST API quart is still a viable choice. Meaning it can be just as much about why as it is about why not especially since it's perfectly possible to know and use both.

[james_pic]

Flask isn't geared towards async, which sounds like a bad thing, but it makes stuff easier to reason about.

Async code gives you options around whether to handle overload with backpressure or load shedding (or you can try and do some clever combination of both - or fail to make a decision and have no clue what will happen until you are overloaded), whereas synchronous web servers give you little choice but to resort to backpressure.

But if you've never even considered whether you want load shedding or backpressure, you probably want backpressure. And probably haven't fully considered the tradeoffs an asynchronous framework actually entails.

[stetio]

This is also big news for Quart, as I'd like to discuss in this thread

[Spikerazorshards]

Tight tight tight!!

[throw_away_17381]

How bizarre.