Python Web Frameworks


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


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 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 is like CGI with a few extensions, and appears to be related to Perl (Wikipedia FastCGI).


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


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 is the latest way to integrate Apache and python. It actually outperforms mod_python for hosting WSGI applications.


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.


  • WSGI reference built-in
  • not production-quality


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


  • 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.


  • 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?


  • 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


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


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



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


  • 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


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


  • 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, or any other WSGI server
  • no dependencies outside of python standard library


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


  • 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


  • 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? ?


  • 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)


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


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.


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


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.


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.


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.