[HN Gopher] Flask 2.0
___________________________________________________________________
Flask 2.0
Author : avyfain
Score : 159 points
Date : 2021-05-12 17:38 UTC (5 hours ago)
(HTM) web link (flask.palletsprojects.com)
(TXT) w3m dump (flask.palletsprojects.com)
| memco wrote:
| 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.
| dan_quixote wrote:
| 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
| detaro wrote:
| Pydantic evaluates annotations from other code. Flask just got
| annotations added to its API. very different things.
| icegreentea2 wrote:
| I don't think so. From what I can see, Flask isn't using type
| annotations to drive any runtime behaviors.
| milliams wrote:
| 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.
| colpabar wrote:
| previous discussion
|
| https://news.ycombinator.com/item?id=27125200
| endisneigh wrote:
| 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?
| morvita wrote:
| 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/
| ehsankia wrote:
| Deprecation aside, Flask 2.0 begins adding type annotations,
| which is 3.6+
|
| https://github.com/pallets/flask/pull/3973
| matthiasv wrote:
| Type annotations started with 3.5, 3.6 added type
| annotations for variables.
| bredren wrote:
| 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
| formerly_proven wrote:
| https://www.python.org/dev/peps/pep-0478/
| nijave wrote:
| 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)
| tusharsadhwani wrote:
| The biggest reason of all would be that 3.5 is already end of
| life :)
| 1f60c wrote:
| 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.
| skvark wrote:
| 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).
| remram wrote:
| 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).
| kstrauser wrote:
| 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.
| [deleted]
| matusf wrote:
| Python 3.6 added f-strings which are rather popular and they
| cause syntax error in previous versions of Python.
| nicolaslem wrote:
| 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.
| yuy910616 wrote:
| 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
| TkTech wrote:
| -
| orf wrote:
| Ordering was stable within a process (and within a given
| PYTHONHASHSEED value), but not stable across processes.
|
| They are now insertion ordered.
| TkTech wrote:
| Thank you for the clarification :)
| [deleted]
| morvita wrote:
| 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...
| ehsankia wrote:
| 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.
| detaro wrote:
| 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.
| krat0sprakhar wrote:
| Sincere question - for starting greenfield projects, what would
| make you choose Flask over FastAPI[0]?
|
| [0] - https://fastapi.tiangolo.com/
| easton wrote:
| 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.
| varispeed wrote:
| 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.
| ddorian43 wrote:
| Flask supports gevent.
| minimaxir wrote:
| Note that Flask is more analogous to Starlette, which FastAPI
| extends.
|
| https://www.starlette.io/
| qbasic_forever wrote:
| 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.
| jtdev wrote:
| > "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?
| glutamate wrote:
| > 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?
| qbasic_forever wrote:
| 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.
| meowface wrote:
| 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 dodging 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.
| goatinaboat wrote:
| _You seem to be suggesting that there is a much simpler /
| better alternative. What is it?_
|
| Bottle is the simpler Flask
| Scarbutt wrote:
| Ecosystem around flask is bigger.
| stevenhuang wrote:
| 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`).
| gabereiser wrote:
| 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.
| systemvoltage wrote:
| It's also worth mentioning that FastAPI/Starlette are async
| and a bit more annoying to debug.
| _frkl wrote:
| flask also supports async now, that's one of the main new
| features of this release.
| systemvoltage wrote:
| 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.
| pletnes wrote:
| 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.
| tedivm wrote:
| 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).
| philote wrote:
| FastAPI allows you to define non-async views.
| [deleted]
___________________________________________________________________
(page generated 2021-05-12 23:02 UTC)