Flask is a microframework for Python based on Werkzeug, Jinja 2 and good intentions. And before you ask: It's BSD licensed!
Although this is a micro-framework, it has two dependencies and an interactive web-based debugger. The dependencies are for the Template Engine and for the WSGI server. Is it this WSGI server which provides the interactive debugger. The WSGI server is Werkzeug, which is also made by the same developers. Because of this interactive debugger, this framework appears to be a good starting point for new Python web developers.
Routing is very similar to most micro-frameworks, where an easy to use decorator is placed before your view function to tell the framework which URLs map to this view. This approach both has it's positives and negatives, but since this is a micro-framework, it makes sense to use this approach.
As noted above, the included Template Engine is Jinja2. I am sure you can use other template engines as well, but since this is dependency during install, you may wish to look into another framework, if you plan on using a different template engine. Rather than this micro-framework providing optional hooks like other micro-frameworks do for the template engine, this framework forces Jinja2 down your throat by having it as a dependency. Also note that the developer of Flask, is also the developer of both required dependencies. I would personally prefer a more pluggable system in a micro-framework. If Flask was to be used on an embedded device, you will need to also download these 2 extra packages, and due to disk space requirements on these devices... I see micro-frameworks as a tool to use on low memory and low disk space situations, they are special purpose frameworks. Most developers will choose a more full-featured framework for larger web applications. Mind you, there are some large websites which do use these micro-frameworks to serve up their main content to the masses, so it is up to the developer to choose the right framework for the job.
Since the Template Engine is Jinja2, and if you are planning on moving from a Django solution to a micro-framework for some odd reason, this framework might be an ideal choice. However, since Jinja2 can be installed on any framework, this does't make it an exclusive option for this. For those who do not know, Django's template engine is heavily based on Jinja2, so converting templates from Django to Jinja2 doesn't take much effort at all, or converting the other way around for that matter.
While going through their Flaskr tutorial, I decided to not copy and paste their import list into my source code as I wanted to see if my development environment can manage the imports for me... Bad idea. For some reason, a few functions failed to be auto-imported, namely g, and abort. For those out there who love managing their imports in their IDE, Flask may break this habit very fast and may even frustrate you during development. I especially love using auto-imports when attempting to learn a new Python package, it helps me understand where everything is located, and what's available. Especially if I forget to add something during development, it makes adding their imports a cinch. In Flash, all the imports are bound to the main Flash module:
from flask import Flask, request, session, g, redirect, url_for, \ abort, render_template, flash
After completing their tutorial, I did feel overall more knowledgeable about their framework, and they do explain each step and what it is doing. I did not feel confident enough to take on a brand-new project using their framework however. Although Flask does have some very interesting concepts, there are other micro-frameworks which I will consider first, if I need a smaller framework.
I will not touch on the templating engine, as that is the scope of an entirely different review, since Jinja2 is a separate Python package. This will be reviewed when I go through the various templating engines available and provide my input on them.
Flask supports different configuration types, mainly Python-based and INI-based. There is a good amount of options available, and custom options can be introduced for your applications purposes. Accessing these options are very straightforward as well, app.config can both set configuration options and return them back to use in the application. This makes it possible to change configuration options at runtime. I am not entirely sure if this is something you may want to do, but the option is there for you to exploit.
In Flask, views will not normally allow any HTTP methods which provide effects, like POST, while coding your views, you will need to remember to tell the route that it will allow POST requests, or it will not. Here's an example which also takes the dynamic configuration into account from the last paragraph. This view can be used in the tutorial they provide:
@app.route('/update_username', methods=['GET', 'POST']) def update_username(): if not session.get('logged_in'): abort(401) if request.method == 'POST': app.config['USERNAME'] = request.form['username'] flash('Username updated') return render_template('update_username.html', username=app.config['USERNAME'])
I render back the same view to confirm that it did indeed allow me to change the variable during runtime. As noted in the functions decorator, methods explains what will pass into this function. Originally I did not put in the methods and received an error message when I attempted to post this form.
Flask provides a Signal interface, which can be used to do various tasks in your application during the lifetime of a request or during various application states. The interface uses Blinker for sending and receiving signals across the application framework.
Flask supports class-based views called Pluggable Views. I give it a large amount of points for it's MethodView, which is geared for RESTful applications. The examples provided in the document explain how to use it in your own applications. Not many micro-frameworks have moved to class-based views, and it is good to see this here in Flask.
Blueprints is Flask's concept of modular applications. Unlike some framework where there is separation, a blueprint uses the configuration from your main application, such as it's database connection and other goodies. This is very handy for developers who want to distribute specialized components, or if you just want to better modularize your application. Although you can just provide a Blueprint for other developers to download and use, Flask has a better system sharing components, Extensions. These are essentially carefully bundled Blueprints which can be installed from PyPI and imported directly into your application. There is an extensive amount of extensions available to application developers, and I'd recommend looking for an extension which implements the functionality you need before reinventing the wheel. There are some really nifty extensions there, which I am really tempted on playing around with myself to see how well they function.
In the Flask documentation, there is a section there titled Patterns. These are essentially a bunch of code snippets to get you started quickly on a matter of different subjects. This would be a great place to head after completing the tutorial due to the vast amount of knowledge available there.
Overall, Flash is a very fine polished micro-framework, rather it's turning into much more than just a micro-framework, I'd call it a mini-framework, a step up from micro.
- Fully documented using docstrings.
- Has a very powerful web-based debugger.
- Supports RESTful URL routing.
- Development server can serve static files.
- Uses the standard Python Logger.
- Has dependencies, which micro-frameworks should avoid.
- Doesn't play well with auto-imports in Eclipse