Flask 2.0.0 has been merged into master(github.com)

150 pointsby tpfour5 tahun yang lalu53 comments

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

54 comments

chirau5 tahun yang lalu

In case anyone is interested in the major changes in 2.0.x:

https://flask.palletsprojects.com/en/master/changes/

viraptor5 tahun yang lalu

At the very bottom: "Add type hinting."

I love that this happens to larger libraries now. It doesn't need to be 100% complete, but it will still improve many devs' lives. I hope it will become the default for new projects and major updates.

anonymouse0085 tahun yang lalu

How Steve Wozniak wrote anything by paper, much less BASIC for the Apple I, is beyond me...

He and his kind are in a different reality

viraptor5 tahun yang lalu

The scope is much more limited in his case. When the problem space is super narrow and the base language is your whole environment, writing correct code in a big batch is not that hard. On the other hand, dealing with flask and basically the whole stack of everything web at the same time is a different kind of challenge.

HDMI_Cable5 tahun yang lalu

Writing code by hand isn't too bad, especially with a good language like LISP. I don't think it requires too much extra effort, just more attention and care as to not make syntax mistakes. With near-instant compile times and auto-linting, we sort of lose the ability to auto-vet code before inputting it.

StreamBright5 tahun yang lalu

I think it is a bit deep than that. I love LISP to death but I would never trade a ML language for LISP for writing code that goes into production.

coldtea5 tahun yang lalu

Many people put Lisp into production, even in very demanding environments, just fine...

StreamBright5 tahun yang lalu

I never doubted that.

Erlangen5 tahun yang lalu

> Warning: This is the development version. The latest stable version is Version 1.1.x.

I couldn't find a way to close the top banner. So I clicked around and found out this page had a bug. In the bottom right corner there is button to select the version of flask.

1. click v2.0.x, works fine

2. click v1.1.x, 404 page not found

3. click v2.0.x again, 404 page not found

nerdbaggy5 tahun yang lalu

I have moved most of my stuff to FastAPI. It’s so much more enjoyable than flask. https://fastapi.tiangolo.com/

tootie5 tahun yang lalu

No one ever lists the features I really want. Like, will I understand it 6 months after I wrote it. And do the stack traces point to exactly what went wrong. I generally find any framework that's easy to get started is harder to maintain.

jaza5 tahun yang lalu

Nice, I'll have to try it out - Swagger UI has always been a pain with various add-ons in Flask, and it looks like it's built-in and easy with FastAPI.

Flask is still my go-to Python web framework. Ten years on, and I haven't stopped loving how small, elegant, and flexible it is. It set the bar for many other similar projects.

mikepurvis5 tahun yang lalu

I've been working on an async project for a while using Sanic, and it's just crazy what a long shadow Flask has cast over the whole Python web framework ecosystem— there's just a default assumption that whatever you're doing, it needs to basically have the interface and ergonomics of Flask.

taf25 tahun yang lalu

As casual python user I found Flask really nice for my projects

nr2x5 tahun yang lalu

Agree, went from rough concept to PoC in an hour with Flask.

kortex5 tahun yang lalu

IMHO, FastAPI is more obvious and less magical than Flask. Give it a shot, its super easy to write endpoints.

kordlessagain5 tahun yang lalu

Don’t need to replace what is already obvious from use of a great project, Flask.

kordlessagain5 tahun yang lalu

Yes, very much enjoyable.

holler5 tahun yang lalu

Nice, I'm using Starlette on it's own and it's been really nice to work with.

wilsonfiifi5 tahun yang lalu

Both frameworks can coexist in the same codebase if you use the WSGIMiddleware module [0]. It's a bit easier to get it running with Flask than with Django. The issue with Django is getting the static assets to work. The easiest way I've found is to run collectstatic in Django and serve the output folder through FastAPI.

[0] https://fastapi.tiangolo.com/advanced/wsgi/

dheera5 tahun yang lalu

I've moved most of my Flask projects to Express and NodeJS.

Flask was just a PITA to deploy properly in a way that it could handle lots of concurrent connections without a massive memory footprint, and async in Python is a mess.

The JS ecosystem has on the other hand moved to async and Promises as the standand/default way to implement things, which makes things much easier.

Express middleware is also just easier to write than Flask middleware.

dayjah5 tahun yang lalu

> and async in Python is a mess

I’ve heard this a lot of late, but it’s not clear to me why. Would you be willing to expand on your assertion?

Personally, I’ve written a fair chunk of typescript and asyncio based Python over the year for a project and in general I think Python has done an excellent job of their implementation.

Some things are annoying; for example I’ve a consistent case, which I haven’t pared down to better understand, where by exceptions in a coro are never visible. Not to be confused with the classic case of being notified of the exception when your process shuts down.

OTOH some things are really amazing, for example PYTHONASYNCIODEBUG=1. More so the ability to wrap non async, typically blocking, code in an Executor and it “magically” (via thread pools) work in the event loop has also been a boon for the type of work I’m engaged in.

Waaaaay back, I was really hurt by twisted and to a lesser extent tornado. But the async stuff shipped in 3.9x seems completely comparable to JavaScript imho.

dheera5 tahun yang lalu

The main problem is that many Python libraries come in only sync flavor and using them together with asyncio is a pain.

NodeJS libraries are almost all standardized to async now. Hell, even Tensorflow.js can give you Promises of computation results.

heavyset_go5 tahun yang lalu

Seems pretty painless to me:

    $ python3 -m asyncio
    >>> from requests import get
    >>> url = 'https://example.com'
    >>> response = await asyncio.to_thread(get, url)

A lot of Python libraries now offer async APIs, have async support on their short term roadmaps, or other async projects have replaced them.

dayjah5 tahun yang lalu

oh neat! I did not know about asyncio.to_thread; I've been using the longer form thread executor pattern.

simonw5 tahun yang lalu

I hadn't seen that either - looks like it's new in Python 3.9: https://docs.python.org/3/library/asyncio-task.html#asyncio....

heavyset_go5 tahun yang lalu

And if you aren't using 3.9, the anyio package has a run_async() function in its to_thread module[1] that works the same way as asyncio's to_thread() coroutine function, and the anyio solution is compatible with both asyncio and trio.

[1] https://anyio.readthedocs.io/en/stable/threads.html

postpawl5 tahun yang lalu

You looked into using gevent workers? Sometimes you need to make tweaks to C-based dependencies to make them not block the event loop, but it should work fine for doing a lot of concurrency without a bunch of rewriting. Usually your bottleneck is your database anyway.

avinassh5 tahun yang lalu

How does gevent actually works? It takes care of scheduling and polling?

ghostwriter5 tahun yang lalu

it uses non-blocking sockets and libev interface to propagate events from the kernel https://sdiehl.github.io/gevent-tutorial/#greenlets

cylde_frog5 tahun yang lalu

If you like Express and writing middleware in Express, you will love Koa. Its written by the same team that wrote Express so it will be familiar. It makes more use of async/await than Express too.

akvadrako5 tahun yang lalu

If you only need 10.000 concurrent users it's pretty easy to do that with threads and gunicorn or uwsgi.

The memory footprint shouldn't be bad, just one page per user.

1_player5 tahun yang lalu

> The JS ecosystem has on the other hand moved to async and Promises as the standand/default way to implement things, which makes things much easier.

Weird, none of the issues in my career as a full stack dev ever have been due to a lack of async primitives.

There are much more elegant ways of doing concurrency than Promises and coloured (async vs regular) functions, if that's the issue.

crazypython5 tahun yang lalu

> Flask was just a PITA to deploy properly in a way that it could handle lots of concurrent connections without a massive memory footprint, and async in Python is a mess.

That makes me concerned. Does anyone here know if FastAPI is better? How many concurrent connections could your Express app handle at once?

kortex5 tahun yang lalu

Yes. Night and day. I haven't got too deep into it, but FastApi allows writing async def right out of the box, super easy to set up. Uvicorn is stupid fast and easily configurable. There is also fledgeling asgi (async wsgi) support iirc.

liquidise5 tahun yang lalu

> Drop support for Python 2

Python 3 released on '08. Flask debuted a couple of years later in 2010, on Python 2. 11.5 years later Python 2 is nearly in the rearview. The history of the Python 3 release is surely an impressive one.

On a more related note, props to devs/contributors for this release. My experience with Flask was pop-up projects and never mission critical, but i always found it a joy to use and quite intuitive.

rastapasta425 tahun yang lalu

You would be surprised by the amount of mission-critical code which runs on Flask.

Flask is a great library which gets out of your way - I find it a joy to use compared to Django.

Although there are some dark sides, particularly with how Flask interacts with Werkzeug during exceptions when you need CORS (for example, we can't overwrite exception page's Access-Control-Allow-Origin headers with @app.after_request since these headers are set by Werkzeug and can't be overwritten in Flask).

This prevents us from levering Flask's default except handler in certain environments which require custom headers for exception handling page.

Nicholas_C5 tahun yang lalu

> Flask is a great library which gets out of your way - I find it a joy to use compared to Django.

Agreed. I found Flask after being really annoyed with learning Django. Flask + Heroku is an awesome combo for the hobbyist like myself.

mvolfik5 tahun yang lalu

How are these set in werkzeug? Sound like you would be using the werkzeug dev server then...

But this works for me:

    @app.errorhandler(ApplicationError)
    def handle(e):
        resp = e.args[0]
        resp.headers["Access-Control-Allow-Origin"] = "..."
        resp.status_code = 500
        return resp

    @app.route("/err")
    def err():
        raise ApplicationError(jsonify({"reason": "test"}))

rastapasta425 tahun yang lalu

I'm aware about the ability to overwrite error handler with a custom code, but Werkzeug's handler already supports pretty stack traces and much more, and I would rather not re-invent the wheel from scratch.

I was talking about using werkzeug's builtin exception handler but with custom headers - which doesn't appear to be supported.

mvolfik5 tahun yang lalu

that is not supported. But why would you want to serve that with CORS headers? It's only meant to be displayed in the browser and in dev environment, not production

rastapasta425 tahun yang lalu

I am disappointed this release does not introduce any functionality similar to the Flask-Classful project.

I find built-in MethodViews very limited and unable to capture context.

Furthermore, MethodViews force you to artificially split endpoints between multiple classes when functionality better belongs in a single class.

https://flask-classful.teracy.org/#using-custom-routes

whalesalad5 tahun yang lalu

This is huge. (Serious!) https://github.com/pallets/flask/pull/3907

    Add route decorators for common HTTP methods. For example, 
    @app.post("/login") is a shortcut for 
    @app.route("/login", methods=["POST"]).

rastapasta425 tahun yang lalu

> This is huge.

I consider this to be a minor syntactic sugar.

kstrauser5 tahun yang lalu

It’s not rocking my world, but I know which one I’d rather grep for (especially if the methods kwarg got pushed down to another line due to formatting).

whalesalad5 tahun yang lalu

Considering it’s a very common touch point as a flask developer it’s great to see.

[deleted]5 tahun yang lalu

lettergram5 tahun yang lalu

Honestly, I thought flask was mostly just in maintenance mode. Glad to see it progress!

rastapasta425 tahun yang lalu

No point in iterating once you reach perfection.

viraptor5 tahun yang lalu

Definitely not perfection. But yes, we shouldn't see "complete project" as a bad thing.

systemvoltage5 tahun yang lalu

> Add route decorators for common HTTP methods. For example, @app.post("/login") is a shortcut for @app.route("/login", methods=["POST"]). #3907

Why? By default, it’s GET if you don’t specify a method. But now with this change, for special routes such as “/login” it’s POST. IMO these kinds of things make for “gotcha” moments. Just keep defaults simple without special exceptions.

Hasnep5 tahun yang lalu

I think you've misread the change, it's nothing to do with login being a special case, it's about moving the HTTP method from the methods argument to the function name.

systemvoltage5 tahun yang lalu

Yes I did. Thanks!

zild3d5 tahun yang lalu

"common HTTP methods" meaning GET, POST, PUT, PATCH, DELETE not "/login", etc (those would be routes)