Flask 2.0 | Hacker News Reader

Flask 2.0

flask.palletsprojects.com

202 pointsavyfain49 comments

previous discussion

https://news.ycombinator.com/item?id=27125200

Sincere question - for starting greenfield projects, what would make you choose Flask over FastAPI[0]?

As others mention, Flask has more batteries included in terms of built-in templating, ORM, etc, so it positions more as a backend webserver.

FastAPI is more focused on making it easy to make APIs, especially with the built-in Swagger docs generation (I don't believe Flask has this out-of-the-box).

So if your greenfield project is more web-based (clients are web browsers), Flask may be more suited. If your greenfield project is service-based (command line applications, or front end), FastAPI may be more suited.

In both cases, it's as easy to substitute one for the other. Personally I'll be trying out FastAPI since the dev experience seems a lot nicer (integration with `pydantic`).

It's also worth mentioning that FastAPI/Starlette are async and a bit more annoying to debug.

flask also supports async now, that's one of the main new features of this release.

I believe Flask 2.0 optionally supports it whereas FastAPI is async only. I could be wrong though.

Edit: Thanks for the correction, my point is moot and irrelevant.

FastAPI happily supports both options in a gradual manner. Just start out sync and convert to async if you want on a per-route basis.

That's not exactly accurate. When working with sync views FastAPI dumps them into a threadpool. It basically converts them to async on the fly. To quote the docs-

> When you declare a path operation function with normal def instead of async def, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server).

FastAPI allows you to define non-async views.

pip install flask-swagger flask-swagger-ui

Flask itself doesn't support swagger out of the box (much like security or login/auth) but the community has you covered.

I wonder why should someone use either of those, if typically you'll end up with something Django like but less pretty? I sometimes use Flask if I need to spin up a tiny API, but for something bigger DRF and Django just saves time. I get that this stack is boring, but is battle tested, has no surprises and just works. If I need performance then I go for Golang.

For us, it's because we want more capabilities in our ORM and so use SQLAlchemy+Flask.

Why you cannot do with Django ORM that you can with SQLAlchemy?

Flask has built in templating via Jinja2, FastAPI makes you hook up the templating library you want yourself. Not a big deal (I think it is literally like five lines or something) but if you are building a normal web app without a bunch of AJAX or a SPA on the frontend that might be relevant.

Note that Flask is more analogous to Starlette, which FastAPI extends.

https://www.starlette.io/

I'd start with the higher level question, do I want a production Python deployment and all the headaches of deploying, managing, scaling, etc. that come with it? There are some fantastic things in the Python ecosystem that might make it worth going down that route. But if you're just chucking some templates at the results of basic CRUD API operations or simple business logic, etc. you might not need those headaches.

IMHO go with whatever one you know and don't depend too much on any special features or framework-specific things that aren't critical. You're likely going to throw away and rewrite whatever you produce many times throughout its lifetime if it gets some legs and grows.

> “do I want a production Python deployment and all the headaches of deploying, managing, scaling, etc. that come with it?”

What “headaches” have you encountered with Python/Flask in relation to deploying, managing, scaling? Specifically, what headaches have you encountered that are not present in every platform/language? Are you a NodeJS dev?

> production Python deployment and all the headaches of deploying, managing, scaling

You seem to be suggesting that there is a much simpler / better alternative. What is it?

You seem to be suggesting that there is a much simpler / better alternative. What is it?

Bottle is the simpler Flask

I'm not being baited into that argument. If you're starting a greenfield project then one of the first priorities is picking the tech stack and considering all of the trade-offs therein. In some situations you and your operations team might value deploying a static binary with zero dependencies to manage--Python is not a good choice there. Or in other situations you might depend on scientific code and models which are difficult or impossible to port away from Python. There's no simple answer to your question.

Respectfully, I think you were the one who was perceived as baiting people with your initial post because it seemed to be hinting in an aside that any Python project in general is difficult to deploy and then not elaborating; then kind of seen as further baiting people after multiple replies inevitably constructively asked you for clarification on what you were referring to and you seemingly dodged the question by saying they were baiting you and that you won't dignify them with an answer.

It seems like it was probably just a misunderstanding due to an ambiguous way someone could interpret your post. I see what you likely actually meant, now, and that you probably weren't talking about some issue with Python but about different levels of complexity in deployment in general, but I also initially misinterpreted it like the other posters did and thought it was a jab at Python.

So everyone was basically misunderstanding everyone else and mutually thought they were being baited even though they weren't, I think.

Ecosystem around flask is bigger.

Flask supports gevent.

Can anyone surmise if the flask type hinting is vulnerable to annotations issue that pydantic/fastapi recently faced?

https://github.com/samuelcolvin/pydantic/issues/2678

I don't think so. Pydantic and co. were using the annotation system in a quite in-depth way to generate their special classes. Flask just seems to be using type annotations like any other Python library would.

I don't think so. From what I can see, Flask isn't using type annotations to drive any runtime behaviors.

Pydantic evaluates annotations from other code. Flask just got annotations added to its API. very different things.

Can someone comment on the benefits these changes have? Is it faster, more memory efficient, etc.? The change log has a lot of the technical minutiae of how I would need to change the way I use some things, but not the why.

I'm surprised that it doesn't support Python 3.5. I've been a bit out of touch with Python - is there something that changed significantly in subsequent versions to justify this?

Flask's creator, Armin Ronacher, was asked on the Real Python podcast in July 2020 what specifically he would have done differently.

He said he under appreciated how big the community would get but also the number of people who would use it.

He faulted himself for not spending time thinking about the transition from him primarily working on it to others. And that he should have been thinking about how things would work when he was not involved.

The specific item he was concerned about was that he did not work to build a "community of like minded people" which he says Django did a much better job at doing.

At the very end of the comment, he openly considers if there are things he should have done differently:

"I probably would feel less detached from it if I would have communicated some of my ideas more.

I feel like it is no longer my fight to make it more backwards compatible for instance. The community sees this differently than I do, so that's fine."

https://realpython.com/podcasts/rpp/58/#t=1202

Python 3.5 was declared end of life in September 2020, so it makes sense for library developers to drop support for it as well. Something like Flask 2.0 may work in Python 3.5 (I haven't tested it myself), but it isn't worth the developers' time to guarantee that support for a language version getting no support upstream.

https://www.python.org/downloads/release/python-3510/

Deprecation aside, Flask 2.0 begins adding type annotations, which is 3.6+

https://github.com/pallets/flask/pull/3973

Type annotations started with 3.5, 3.6 added type annotations for variables.

3.6 had a couple of big improvement - f strings, annotation, and if I'm not mistaking, the devs did something to improve the dictionaries; from 3.6 on dicts are ordered.

I don't know too much about it but raymond hettinger gave a talk about it. https://www.youtube.com/watch?v=p33CVV29OG8

Considering the last item in the changelog is:

- Add type hinting. https://github.com/pallets/flask/pull/3973

I think it's fair to assume annotations is the big reason.

Annotations were added in 3.5, so no reason to drop 3.5 for them, and 3.5 support had been dropped from Flask over a year ago.

Order-preserving dicts were added as a side effect of an optimization in CPython 3.6 [0]. They were considered an implementation detail of CPython in 3.6, it wasn't until Python 3.7 that is was declared an official part of the language [1].

[0] https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-compa... [1] https://mail.python.org/pipermail/python-dev/2017-December/1...

Ordering was stable within a process (and within a given PYTHONHASHSEED value), but not stable across processes.

They are now insertion ordered.

Thank you for the clarification :)

3.5 has been EOL for 8 months now. (Source: https://endoflife.date/python)

I’m guessing they want to tell people it’s time to upgrade. And 3.6 brings a lot of niceties that they might want to use, like f-strings.

Many projects are dropping support for old Python versions very fast. It's not surprising given the history of the Python 2 -> 3 transition. No one wants to end up in that situation anymore. For example, NumPy has already dropped 3.6 support (3.6 will be EOL later this year).

I don't know about "very fast", Python 3.6 was released in 2016 giving people plenty of time to update from 3.5. Those are backward-compatible too.

If you haven't updated in that time, you probably have a systemic problem which shouldn't be blamed on Python moving too fast (in fact I suspect those people don't keep up with bugfixes either, so nudging them to upgrade when they try to update flask/numpy is a good idea).

That’s what I’ve done on personal projects. The benefits of dropping support for the old version are large enough to outweigh the tiny drawbacks of not supporting it.

Python 3.5 is end of life, as it doesn't receive security fixes anymore no one should really use it for production.

I imagine that removing it from the supported versions in Flask allows for example to use f-strings.

Python 3.6 added f-strings which are rather popular and they cause syntax error in previous versions of Python.

Afaik the Python foundation supports the current and 3 previous Python releases and many developers track CPython interpreter support. Can't find a link to n+3, though

(Current is 3.9 so 8,7,6 are also supported)

The biggest reason of all would be that 3.5 is already end of life :)

https://www.python.org/dev/peps/pep-0478/

Reply on news.ycombinator.com