Flask 0.5 Released - Python WSGI microframework
pypi.python.org
pypi.python.org
What's new:
* 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.
Online Documentation: http://flask.pocoo.org/docs/
Downloadable PDF: http://flask.pocoo.org/docs/flask-docs.pdf
Website: http://flask.pocoo.org/
On Github: http://github.com/mitsuhiko/flask
PyPI Record: http://pypi.python.org/pypi/Flask
I'm waiting for an excuse to try this project out :)
In this context marking is everything.
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.
Flask has a growing community of contributors. See the extensions library: http://flask.pocoo.org/extensions/
In a nutshell, Bottle is suitable for very simple websites. Flask has what it takes to grow into a large site.
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.
i am finding choosing a python framework to be stressful.
It is stressful.
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).
Example: Everyone seems to think that Google copied "their" Python web framework in creating the "webapp" framework for App Engine. webpy, Django, ...