Some really interesting ideas here, especially coming at it from a Django background.
Flask embraces thread locals - Django tends to pretend they aren't necessary at the user level, even though there are a few of them lurking in the core framework. Flask's request object is thread-safe global, and Flask encourages you to put your own per-request global instances (such as a database connection which is opened at the beginning of the request and closed at the end) on the special flask.g object. I've always disliked this kind of approach because it makes it hard to run your code outside of the context of a web request (e.g. in a cron script), but Flask deals with that by providing a clever test_request_context method:
from flask import request
with app.test_request_context('/hello', method='POST'):
# now you can do something with the request until the
# end of the with block, such as basic assertions:
assert request.path == '/hello'
assert request.method == 'POST'
Using the with statement here is very smart - Flask seems to get a lot of mileage out of both context managers and decorators.
I'm looking forward to seeing how Flask shapes up - it feels like a very modern attempt at a Python micro-framework, with some pleasantly unconventional ideas.
Armin has stated that he thinks that declaring URL routes with decorators is a bad idea. Has he warmed up to it or decided it bearable being a minimal framework?
I think they are a bad idea. I love urls.py being kind of a TOC for your application. Apart from that I can see a lot of good ideas in here. Solid template and HTTP layers, signed cookies, avoiding the ORM, short lived messaging, proper __html__, simplistic URL reversal. I love the simple request object API (args, form, files).
I can see additional libraries around this core. High level forms library at least.
You don't have to use decorators (they cause issues with circular dependencies as well, making it difficult to break up your views module). There is an add_url_rule method you can use to register views.
An ORM is tangental to Flask - there is some docs on how to use with SQLAlchemy (which also suggests WTForms for validation) but it's ORM/DB neutral, which is a good idea.
However I'm warming to the idea of avoiding an ORM completely in future projects - just use a thin layer around MySQLdb or DB of choice, like tornado.database or SQLAlchemy's query API.
edit: In response to the downvotes - it appears that it was an April Fool's joke, but because of the response he got, Armin decided to try it out for real. Yeesh.
If anyone is trying to follow along with the Quickstart, a simple virtualenv + easy_install Flask didn't work for me -- I needed to install Werkzeug tip (easy_install Werkzeug==dev) and install Jinja2 from tip as well (hg clone http://dev.pocoo.org/hg/jinja2-main jinja2).
I'm not experienced with Sinatra, but web.py is a really elegant little framework. It gives you what you need and then gets out of the way. It's also RESTful and gets its HTTP status codes right.
Reading this the documentation is really easy to read and understand. Doesn't seem to have the restrictions of Django, you could build small distributed apps that communicate over sockets or REST.
Would also hope to see good support with document databases like mongodb.
Not that Python needs more web frameworks (http://wiki.python.org/moin/WebFrameworks), but it's good to see Python use its new poor-man's equivalent to Ruby's block syntax.
Not addressing Flask directly but the article made me think of something about small web frameworks. It strikes me as easier to come up with a new "big" web framework than it is with a new small one. Because after a certain point, its hard to come up with a framework where a Hello World web app can be expressed with any fewer lines of code. It's always possible to make a more verbose web app, it may be impossible past a certain point to make one more concise.
Perhaps Flash's angle could be not to shrink the minimum LOC needed, but to deliver more features per app LOC.
Flask embraces thread locals - Django tends to pretend they aren't necessary at the user level, even though there are a few of them lurking in the core framework. Flask's request object is thread-safe global, and Flask encourages you to put your own per-request global instances (such as a database connection which is opened at the beginning of the request and closed at the end) on the special flask.g object. I've always disliked this kind of approach because it makes it hard to run your code outside of the context of a web request (e.g. in a cron script), but Flask deals with that by providing a clever test_request_context method:
Using the with statement here is very smart - Flask seems to get a lot of mileage out of both context managers and decorators.I'm looking forward to seeing how Flask shapes up - it feels like a very modern attempt at a Python micro-framework, with some pleasantly unconventional ideas.