Python Web Frameworks

Introduction

This started as an attempt to document all the various python microframeworks. However, as could be expected, it cross-links to Macro Frameworks, Object-Relational Mappers, Template Systems, and so on, and I'm gradually compiling all the information into one large inter-linked document.

It's a huge task! Any feedback is appreciated.

Here's a good introduction:

Invocation Methods

WSGI

First I read up on WSGI since it seems to be used by all the frameworks. In a nutshell, WSGI is similar, but not identical to CGI.

Essentially, using WSGI has these benefits:

  • allows for component re-use
  • increases interoperability
  • allows for reusable middleware
  • backwards compatibility

CGI

CGI is the old-school way of invoking programs "under" your web server, and is easy to configure, but not suitable for high-performance web servers.

FastCGI

FastCGI is like CGI with a few extensions, and appears to be related to Perl (Wikipedia FastCGI).

SCGI

SCGI is a python replacement for CGI (Wikipedia SCGI), and is supposed to be similar to FastCGI but easier to implement.

mod_python

mod_python is a way to integrate Apache and python. It performs as well as FastCGI, but is not as straightforward to configure.

mod_wsgi

mod_wsgi is the latest way to integrate Apache and python. It actually outperforms mod_python for hosting WSGI applications.

Flup

WSGI Servers

These are used to map HTTP to WSGI, and replace Apache or lighttpd with one of the above modules to map to WSGI.

WSGIref

  • WSGI reference built-in
  • not production-quality

Fapws3

  • based around libev
  • event-driven
  • very fast
  • very simple

Gunicorn

  • pre-fork worker model based around Ruby's unicorn project
  • Natively supports WSGI, Django, and Paster
  • Automatic worker process management
  • Simple Python configuration
  • Multiple worker configurations
  • Various server hooks for extensibility
  • Compatible with Python 2.x >= 2.5
  • possibly nicer than Fapws3

Object-Relational Mappers

Object-Relational Mapping is a technique that maps between relation database entities (table rows) and python objects.

In this case, a table is like a class, and a row is like an instance of the class.

They're there to serve as a sort of "impedance matcher" between database objects and python objects.

Database Libraries

These python libraries interface between python and the C libraries associated with a particular relational database.

Session Management

WSGI Libraries

These are collections of WSGI helper libraries.

werkzeug

  • collection of utilities for WSGI applications
  • debugger
  • request and response objects
  • doesn't enforce specific Template engine, ORM, etc.
  • TODO: is this a microframework or not?

Paste

  • collection of utilities for WSGI applications and frameworks
  • several hundred tiny reusable tools
  • Middleware to email your errors back to you
  • WSGIRequest and WSGIResponse object
  • Exception handling & debugging
  • WSGI Environment handling routines (query_string parsing, multipart form parsing)
  • Session Management, transaction logging, proxying, mod_python script, static file serving
  • PasteScript - command-line tools simplify project templates for Django, Pylons, Turbogears Frameworks
  • PasteDeploy - config file for middleware, WSGI apps, eases loading of WSGI apps

Luke Arno's WSGI Helpers

  • TODO: finish here

Microframeworks

These typically all implement some kind of URL routing, sometimes called "path dispatching", which is implicit with WSGI.

itty

  • 41 SLOC
  • influenced by Sinatra
  • Not enterprise-ready

juno

djing

  • 43 SLOC
  • Built on Django Frameworks (a microframework built on a macroframework? weird)

mnml

  • 408 SLOC
  • provides routing
  • methods for all HTTP verbs (e.g. PUT and DELETE)
  • ability to add middleware
  • does not dictate type of Templates or ORMs

newf

cherry.py

  • lightweight
  • Template-agnostic
  • Turbogears runs on top of this
  • cherry.py applications are stand-alone python apps running a multi-threaded web server
  • HTTP/1.1 compliant
  • can use Routes for URL routing

bottle

  • routes: maps URLs to code in a simple but powerful pattern syntax
  • supports mako, jinja2, cheetah Templates
  • built-in HTTP dev server and support for Paste, Fapws3, Flup, cherry.py or any other WSGI server
  • no dependencies outside of python standard library

bfg

  • a/k/a repoze.bfg
  • inspired by Zope, Pylons, Django Frameworks
  • well-tested
  • minimalist
  • well-documented
  • fast; 100-1000 r/s

flask

web.py

  • built-in web server
  • does URL routing via regular expressions
  • has its own Template System that supports inheritance and tries to "bring python into HTML"
  • has its own Session Management system
  • user authentication is relatively straightforward

bobo

  • TODO: finish here

Macro Frameworks

This is my attempt to review the various python web frameworks to get a feel for which to chooose.

Similar Frameworks

Google App Engine

  • Has a python (and java) API
  • runs on Google's servers, so not covered here

Feature Matrix

Macro Frameworks - support for Templates

Framework Django Jinja2 Cheetah Mako Genshi Kid Zope Myghty Chameleon Joomla Turbogears
Django DEFAULT djj2Y djchY djmkY djgsY djkdY djzoY djmyY djcmY djjlN ?
Pylons N? pyj2Y pychY DEFAULT pygsY pykdY N? O by Mako ? ? Y
Turbogears N Y P P DEFAULT O by Genshi N Y N ? ?
web2py N N N N M N N N ? Y ?
Zope ? ? ? ? ? ? DEFAULT ? ? ? ?
Grok N grj2Y grchY grmkU grgsY N? DEFAULT N? grcmY N? ?

Key:

  • link ending in Y means YES
  • link ending in N means NO
  • link ending in U means UNCLEAR
  • O means obsoleted
  • P means planned
  • ? means I'm not certain

Turbogears refers to Turbogears plug-in compatible (see TurboDjango, Cheetah, etc.)

Journal (Historical)

Introduction

This is my journal describing my search for a suitable python microframework.

I realize this isn't terribly helpful for those who wish to figure out why to choose one microframework over another, but it's a little better than just a list of frameworks.

Problem Statement

The web service I'm developing is rather simple; I have three tasks, searching, showing results, and downloading information from a (non-relational) database. There is no need for a SQL interface. Also, the results are not going to be in HTML, they will be in JSON so there's no need for a templating system. There will, however, be multiple, optional parameters to the query functionality, so we need form handling.

This seems like a perfect problem for a microframework.

The Frameworks

itty

It has a disclaimer:

Beware! If you're looking for a proven, enterprise-ready framework, you're in the wrong place. But it sure is a lot of fun.

This slightly put me off in working on itty, but I may return to it.

juno

However, juno requires SQLAlchemy, and we have no need for an object-relational mapper, so this is probably too complicated for my purposes.

djing

This is a micro-framework built on a macro framework (django). That sounds a bit like overkill for my project - you don't get something simple by roping in a bunch of complexity.

mnml

This is a small framework, 408 lines of python.

It has a 75-line example, and that got me started. I could render web pages and forms quite easily, but I couldn't figure out how to process the results of a form submission. Every time I tried, I got a "404 Page Not Found" error.

I contacted the author and he intends to whip up an example this weekend.

newf

This is a really small framework, only 144 lines of python.

It is really close to WSGI, which makes it easy to understand.

It has a very short example, from which I was able to get started. I also managed to get a web page with a form to render, as well as submit the results and have that submittal be processed.

This is what I ended up implementing my project in.