Python Paste



Wareweb is a rethinking of the ideas behind Webware. Webware is a fairly old framework, written back in the days of Python 1.5.2, and some of the API decisions behind it now show their age. Also, many of the abstractions in Webware didn't turn out to be useful, while some other abstractions are missing.

Wareweb tries to keep the basic model of Webware, while simplifying many portions and adding some new techniques. It's not backward compatible, but it doesn't require major revamping to apply to a Webware application.

Wareweb also requires Python 2.4; as long as we're updating the API, I want to make it as modern as possible. Decorators in particular are widely used in the framework.


Wareweb was an experiment in framework design. It's a fairly stable piece of software, and some code is build upon it, but further development is not planned. The author recommends looking at other WSGI-based frameworks, like Pylons.


A simple paste.deploy configuration for a Wareweb application named MyPackage looks like:

use = egg:Wareweb
app_name = mypackage
package_name = mypackage
debug = true

You can create a basic package with paster like:

paster create --template=basic_package MyPackage

You'll have to create a mypackage.web package after. An example that hasn't been updated recently, but may be helpful, is available in the repository.


See paste/wareweb/ for a description of the IServlet interface; the online documentation for IServlet is a good description.

Components and Events

There are a couple fairly simple metaprogramming techniques added to Servlet to make it easier to add functionality.

Active Attributes

When you create a class, attributes can be "active". That is, simply assigning the attribute can cause changes to the class.

This is implemented by looking for a special method __addtoclass__ in all new attributes. The dispatchers, for instance, add themselves as "event listeners," so that simply by putting a dispatcher in your class definition somewhere you'll have changed the functionality of the class.


Many methods throw events (with paste.wareweb.event.raise_event). An event is sent to each listener on the object, and the handler can do nothing (returning event.Continue) or can override or respond to the event in some way.

Dispatching objects listen for the end_awake event (called at the end of awake()), and may call an extra method on the servlet based on some criteria (like _awake_ or path_info).

Templating systems can use an event to write a template. ZPTKit overrides start_respond to write the template.

Unpacking Methods

On a per-method basis you can use the algorithms in paste.wareweb.unpack to unpack your request. E.g., something like:

dispatch = MethodDispatch()

def edit_item(self, item_id_int_path, name):
    Item.get(id=item_id_int_path).name = name

This unpacks a request like servlet_name/edit_item/1?name=new_name into the function call. Note that MethodDispatch makes /edit_item call the edit_item() method. @public declares that the method is actually available to the public. @unpack uses the method signature to identify the parts -- item_id_int_path ends with _path, and so will be taken from path_info; and has _int and so will be coerced into an integer.

Automatic Properties

Methods that end with __get, __set and __del will automatically be turned into properties. Subclasses can selectively replace just one of these implementations, while leaving the others in place.

Differences from Webware

This is a rough summary of the differences from Webware. There's lots of little things that are just plain gone; this doesn't enumerate all of them.

No Request And Response

There are no longer request and response objects. There is only the servlet. The servlet contains all the useful methods from these objects.

From the response, several methods:

  • set_cookie
  • set_header
  • add_header
  • write
  • redirect

From the request, several attributes (note: no methods):

  • environ
  • config
  • request_method
  • app_url
  • path_info
  • path_parts
  • fields

For more exact details, see paste.wareweb.interfaces.IServlet

Only One Servlet Class

There's one Servlet for everyone -- no Servlet, HTTPServlet, and Page. All servlets instances are not threadsafe, because they contain information about the request and response in their instance variables. In practice no Webware servlets were threadsafe, nor was there anything to be gained by that.

Also, reusable functionality is not meant to be added with subclasses of Servlet. Subclassing is for the end-developer to add application-specific functionality; there's other techniques for adding reusable functionality.

No _action_ by default

URL dispatching is handled more generically; several dispatchers are available, one which implements the _action_ parsing of Webware. Dispatchers for XML-RPC and JSON-RPC are also possible, and they have their own built-in methods of indicating methods. Other forms of URL parsing are also implemented.