* fixed a bug with subdomains that was caused by the inability to
specify the server name. The server name can now be set with the
SERVER_NAME config key. This key is now also used to set the
session cookie cross-subdomain wide.
* autoescaping is no longer active for all templates. Instead it is
only active for .html, .htm, .xml and .xhtml. Inside templates
this behaviour can be changed with the autoescape tag.
* refactored Flask internally. It now consists of more than a single
file.
* flask.send_file() now emits etags and has the ability to do
conditional responses builtin.
* (temporarily) dropped support for zipped applications. This was a
rarely used feature and led to some confusing behaviour.
* added support for per-package template and static-file directories.
* removed support for create_jinja_loader which is no longer used in
0.5 due to the improved module support.
* added a helper function to expose files from any directory.
It is also an interesting springboard to working directly with Werkzeug, around which Flask is a relatively thin wrapper. Werkzeug is a very featureful library with which one can rapidly create exactly the framework one needs for a given project. No magic, no ponies ;-)
I looked briefly at Werkzeug and I've heard good things about it. I have to confess I was deterred for no better reasons than the name and finding too much resemblance between the start page and the classic "under construction" web page circa 1998.
I'm sensing that Roman's Flask project was born out of frustration with people not getting his Werkzeug and Jinja2 projects - probably because of bad marketing. On 1 April he created a silly little microframework and did all the right marketing tricks (flashy website, code on github, references to "ninja coders" etc.). It was supposed to be a joke, but upon seeing how much interest the project got he went ahead and started glueing these components together properly (that's Flask). Werkzeug was a marketing failure but Flask builds upon these mistakes. The documentation is good, the name is excellent and he's attracted attention through GitHub.
I'm waiting for an excuse to try this project out :)
We've arrived at a very interesting point in the evolution of programming languages. For a lot of tasks there are several functionally interchangeable languages to choose from, so increasingly language choice is a matter of taste and style. Languages are developing the same kinds of brand identity that used to be the domain of cars and clothes.
Werkzeug is great if you need more flexibility than Django. http://wasitup.com uses Werkzeug and I've been very impressed with it. My wasitup.web module is a Werkzug application alongside wasitup.http, wasitup.monitor, wasitup.persistence, and wasitup.mail.
Bottle uses one process-wide application object. Flask supports initializing multiple application objects (such as for testing the app with different configurations).
Flask is built on top of the feature-rich Werkzeug library, which can significantly reduce the amount of code you must write for more complex applications. It is straightforward to refactor Flask out of your code and use Werkzeug directly.
The process-wide application object is a sane default for small applications, but not the only option. You can instantiate bottle.Bottle() and work with that, if you need multiple encapsulated application objects. This is fully supported.
Look for libraries that make working with WSGI as painless as possible. Working with WSGI directly allows you to write modular code that works together gracefully with other WSGI code. Pylons is really just an amalgamation of WSGI modules. Smart people can amalgamate their own modules.
Django was written before WSGI was an established standard. It has the advantages of being established, a relatively large pool of developers, and the admin interface. It has the disadvantage of dictating your project layout, not integrating well with other WSGI modules, and having a large degree of lock-in.
The best options are Flask (for a simple start), Pylons (for more obvious out of the box functionality), WebOb (for a simple and slightly too magical WSGI library), and Werkzeug (for a well-written library that dictates nothing).
Um, what about Web2Py? I must say, so far I've been extremely impressed. It's polished, has batteries included, is very similar to Ruby on Rails in experience, and even has a built-in web-based IDE. (http://www.web2py.com/)
My ill informed opinion: the WSGI specification (i.e., PEP 333) together with a decade or so of cross-pollination seems to have made most Python web frameworks more similar than different. You can opt for more out of the box functionality at the expense of less flexibility, but not much else. (The exceptions seem to be where the code is really old and/or asynchronous.) Django seems to be the BDFL blessed option.
Example: Everyone seems to think that Google copied "their" Python web framework in creating the "webapp" framework for App Engine. webpy, Django, ...
Being able to get off the ground quickly while still determining the structure of your project. Thinking like a system programmer rather than a plugin programmer / integrator. Using the libraries of your choice to implement your site in the best way for your requirements.
What's new:
Links: http://flask.pocoo.org/mailinglist/archive/2010/7/6/ann-flas...