Python Web Frameworks Overview

Home People Web Frameworks Emulation
Python

Note

This document is not actively maintained any more. Fortunately, the material featured here has been used as the basis for a more easily edited collaborative Web site about Web programming in Python - see WebProgramming on the PythonInfo Wiki for more up-to-date information.

Original Note

This document is not complete - it is intended to be the replacement for the Python Web Modules Overview, whose purpose has been changed to being an elementary catalogue of modules and frameworks which are not covered here. It is recommended that for comprehensive details of module availability, the Vaults of Parnassus be consulted.

Clearly, the focus of this document will be different from its predecessor, and more about this can be found below.

Note to Developers

What I would really appreciate are answers to the following questions, particularly if your framework is not yet included in the lists below:

What is it that makes your framework different from or better than the other frameworks?
This could be seen as advocacy, but by providing information like this, developers can decide whether the focus of your framework is compatible with their perspectives or needs.
What is (or initially was) your motivation to develop the framework?
Something which is often said about open source development is that people are usually motivated to start a project because everything else does not quite fit their needs. This question attempts to assess whether this was the case with your framework, and whether it still is.
In which ways do you see the framework developing?
Is the framework going to remain "small, simple and focused on doing one thing well" or are there higher ambitions? This is quite important for developers because the answer to this question will dictate whether they will need to integrate your framework with other frameworks and systems, or whether they will need to extend your framework.
What kinds of applications are most suited to the framework?
If your framework was designed to support a particular kind of application well, then developers of such applications will surely want to know!

I feel that some qualitative information about each framework might help people to choose the most appropriate framework for their application. Indeed, I intend to publish the actual responses, if permitted, so that people can make their minds up about each framework by themselves.

Abstract

Since August 2000, following discussion on the Python Web modules e-group (now a dormant Yahoo group) about the availability of Web modules and frameworks for Python, the Web Modules Overview attempted to provide a guide to such frameworks and their features. At the outset, Zope was the only prominent Web applications framework or platform, having been recommended extensively on the Python mailing list and comp.lang.python, but with some dissatisfaction with Zope amongst a number of developers, several alternative frameworks were in the process of initial development. After several months, many of these new frameworks remained limited in scope, or were abandoned; those which continue in active development today are the subject of this document - a document which aims to surpass the Web Modules Overview: the Python Web Frameworks Overview.

One of the confusing aspects of using the word "modules" in a document title is the precise meaning of that word in a Python context: many systems designed to make Web application development easier in Python are more than single modules or small collections of modules; instead, they are usually complete systems comprising packages of modules, tools, applications and, of course, documentation. The term "framework" is more encompassing: typically, frameworks not only provide packages of modules, but also techniques and even methodologies for developing with the software components provided.

This document contains a description of each of the major Python frameworks for developing Web applications. Many of the "modules" mentioned in the Python Web Modules document have been excluded due to lack of apparent maintenance or lack of functionality. Indeed, many of the frameworks listed in this document could be referred to as "application servers" because they all attempt to provide support for the development and deployment of complete (Web-based) applications.

Author: Paul Boddie (paul@boddie.org.uk)

Criteria

Each framework is described in terms of criteria which should help in the comparison of different frameworks. Certain terms are employed and these are clarified below.

Licence

Software licences state the conditions under which a piece of software may be used or deployed. For application frameworks and platforms, they may place restrictions on the modification (and subsequent redistribution) of the framework, the development (and distribution) of extensions to the framework and, in rare cases, on applications developed for/in the framework. Particularly in the first two cases, the licence chosen by a framework's copyright holder may affect the willingness for other developers to assist in the development of the framework or platform concerned.

Any licence descriptions not referring to widely-used licences such as the GPL, those using the suffixes "-like" or "-style", and those using subjective terms such as "liberal", are purely one interpretation of the licence used by the module or framework in question. Definitive licence information must be obtained by visiting the software's licence page or by examining licence declarations in the software's source code or accompanying documentation. I accept no responsibility for the failure of any person or organisation to comply with software licence requirements, particularly where their understanding of a licence is based solely on the descriptions given here.

Deployment Platforms

It is usual for Web application frameworks to make use of existing technological infrastructure to provide an environment for application development. In other words, such frameworks do not always implement all of the services required to deploy and run a Web-based application. Therefore, developers who wish to use a particular framework need to be aware of how that framework integrates with other software components - these other components are the software platforms which the framework itself is deployed on.

Many Python frameworks for Web applications integrate with (or are deployed on) "traditional" Web server software, such as Apache Server, using a number of mechanisms including Common Gateway Interface (CGI) and Web server plug-ins. Some frameworks attempt to provide the functionality of a Web server, with consequences for maintenance, deployment issues, and so on.

The deployment platforms (and issues) can exclude certain frameworks from certain environments; for example, restrictive application hosting environments forbid the execution of "long-running processes". Coverage of the suitability of a framework will therefore be included in the description of each framework.

Development Interfaces

Whilst Python frameworks are likely to encourage the use of Python source code to implement functionality, the nature of this code can take a number of different forms. An example of a recognisable development style is that of a CGI-based program which uses the Python library's cgi module (or an equivalent replacement) to provide access to the details of incoming Web requests. Some frameworks may encourage the "CGI style" whilst others encourage a "servlet style", inspired by Java servlets, which promotes object-based "request handlers", as opposed to Python programs or modules.

This document describes the nature of the code required to implement an application by associating each coding style with a number of recognisable style types, at least where this is appropriate.

Environment Access

In order for "handler" components to integrate with other application functionality, such as common "business logic" which may be shared between applications or different application portions, certain mechanisms may be provided to locate such functionality, as well as shared or external resources and the general environment of the underlying platform. Some frameworks may principally use the standard Python import mechanism to find packages, whereas some frameworks may provide other means to access different environments - Zope's object database offers an environment which combines resource and component access, for example.

Session, Identification and Authentication Support

The use of the term "session" on its own can be confusing, especially in the context of the terminology of particular Web frameworks. Therefore, this document uses the following terms:

Session
Something which identifies a participant in a Web transaction as a distinct visitor, agent or user. Session implementations must exclude the possibility of confusing two different visitors (believing that they are identical) or refusing to acknowledge the identity of a previous visitor as the same visitor upon subsequent visits.
Identity and Identification
The identification of a visitor permits the continued recognition of such a visitor as a distinct and known participant in Web transactions. However, identification alone does not assign any meaning to the assigned identity.
Authentication
The assignment of additional meaning to a visitor's identity, relevant to the application, making that visitor a genuine user of the application. Such additional information can be used by an application to determine which actions are available to the user.

Persistence Support

In the context of Web applications, the term persistence is frequently used to mean "the recording of visitor-related information which can be reused upon subsequent visits by the same visitor". Thus, persistence is often used to record session information, although certain kinds of Web applications may involve the interaction of users with shared or underlying resources, and persistence can also be taken to mean "convenient access to application resources".

Presentation Support

Although other documents and resources exist which catalogue template and presentation system implementations, it is still worth documenting the presentation mechanisms which are supported as "first class" in the different frameworks. Such integration between frameworks and presentation systems can be seen in certain systems such as PHP and ASP, while JSP remains a "preferred" presentation technology for many J2EE-based applications.

Frameworks

The following frameworks will be covered in depth: