The folks at mems-exchange.org released a new version of the Python web application / site-management framework QP and supporting packages.

All of today's released packages support Python >= 2.4, which includes Python 3.1.

They also released an update to Durus, a compact and mature Python object database (which at its core operates like a minimal ZODB/ZEO work-a-like). The API to a Python object db is simply Python.

Key-value databases appear to be in vogue these days. Python developers with an interest in key-value databases may want to check out Durus (or ZODB): the key-value database you already know, and more.

More means more than key-value pairs and simple types. More means virtually any Python object / type. More means more than simple string or integer keys and simple values and offers not only persistent dictionaries but also persistent lists and sets, and persistent objects of most any design you may wish to implement.

Durus has no other package dependencies and is compact. Weighing in with less than 5000 lines of code it small enough to read in one sitting if you want to see how things tick. Or you can just dive in - start a server durus -s and a client durus -c and play.

Earlier this month Chris McDonough posted profile summaries of four Python web frameworks: repoze.bfg, Django, Pylons, and Grok.

The framework I use, QP, supports WSGI but doesn't depend on it, which is neither good nor bad but perhaps as a result I'm a little less aware of the WSGI ecosystem than I should be so I am trying to find time to look at various middleware and application components.

Following up on Chris's post I took the profiling middleware from repoze.profile for a spin to satisfy the latent WSGI curiosity percolating here under the covers. Using paste.httpserver failed for reasons I cannot at this time recall, yet driving the middleware and QP via the basic WSGI reference server was successful. I suppose I'll track that down when I have a real need.

Compared to the list of results in "What's Your Web Framework Doing (2)", QP fits in with the Django results, returning 57 lines of profiler output for a simple GET request from a hello, world application.

I should point out that you can profile any QP application from the included interactive console which provides access to the profiler, as well as to the Durus Python object database containing your application's objects:

$ qp -i hello
Profile, publisher, site
>>> p = Profile('/')
>>> p.stats.strip_dirs()
<pstats.Stats instance at 0x875e7ac>
>>> p.sort('time')
>>> p.format()
Wed Feb 18 18:08:33 2009    /tmp/tmpQJy4QF.profile

         105 function calls in 0.007 CPU seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.004    0.004    0.006    0.006 <string>:1(<module>)
        1    0.000    0.000    0.001    0.001 response.py:375(write)
        1    0.000    0.000    0.000    0.000 :0(now)
        5    0.000    0.000    0.001    0.000 response.py:320(generate_headers)
       12    0.000    0.000    0.000    0.000 utils.py:44(as_bytes)
        1    0.000    0.000    0.007    0.007 profile:0(hit, page = process())
       17    0.000    0.000    0.000    0.000 :0(isinstance)
        7    0.000    0.000    0.000    0.000 :0(write)
        1    0.000    0.000    0.000    0.000 response.py:123(__init__)
        7    0.000    0.000    0.000    0.000 :0(get)
        1    0.000    0.000    0.003    0.003 profiler.py:50(process)
        1    0.000    0.000    0.000    0.000 hit.py:32(init_response)
        1    0.000    0.000    0.000    0.000 request.py:202(get_header)
        1    0.000    0.000    0.000    0.000 request.py:105(__init__)
        1    0.000    0.000    0.000    0.000 request.py:330(_parse_pref_header)
        1    0.000    0.000    0.001    0.001 publish.py:94(process)
        1    0.000    0.000    0.000    0.000 common.py:61(site_now)
        1    0.000    0.000    0.000    0.000 :0(setprofile)
        1    0.000    0.000    0.001    0.001 hit.py:25(__init__)
        1    0.000    0.000    0.000    0.000 response.py:239(set_body)
        1    0.000    0.000    0.000    0.000 request.py:306(get_encoding)
        2    0.000    0.000    0.000    0.000 spec.py:737(get_specified_attribute)
        1    0.000    0.000    0.000    0.000 rfc822.py:952(formatdate)
        1    0.000    0.000    0.000    0.000 slash.py:19(process_hit)
        1    0.000    0.000    0.000    0.000 request.py:373(parse_cookies)
        2    0.000    0.000    0.000    0.000 response.py:361(generate_body_chunks)
        1    0.000    0.000    0.000    0.000 response.py:156(set_status)
        1    0.000    0.000    0.000    0.000 response.py:293(get_content_length)
        1    0.000    0.000    0.000    0.000 common.py:23(get_publisher)
        2    0.000    0.000    0.000    0.000 :0(items)
        1    0.000    0.000    0.000    0.000 response.py:300(_gen_cookie_headers)
        1    0.000    0.000    0.000    0.000 response.py:203(_compress_body)
        2    0.000    0.000    0.000    0.000 :0(getattr)
        2    0.000    0.000    0.000    0.000 response.py:144(set_compress)
        2    0.000    0.000    0.000    0.000 tz.py:60(dst)
        1    0.000    0.000    0.000    0.000 tz.py:40(now)
        1    0.000    0.000    0.000    0.000 response.py:228(_encode_chunk)
        1    0.000    0.000    0.000    0.000 :0(sub)
        1    0.000    0.000    0.000    0.000 :0(time)
        1    0.000    0.000    0.000    0.000 :0(finditer)
        1    0.000    0.000    0.000    0.000 :0(replace)
        1    0.000    0.000    0.000    0.000 :0(split)
        1    0.000    0.000    0.000    0.000 :0(gmtime)
        1    0.000    0.000    0.000    0.000 :0(match)
        1    0.000    0.000    0.000    0.000 response.py:197(set_expires)
        1    0.000    0.000    0.000    0.000 tz.py:54(utcoffset)
        1    0.000    0.000    0.000    0.000 :0(upper)
        1    0.000    0.000    0.000    0.000 :0(getvalue)
        1    0.000    0.000    0.000    0.000 response.py:133(set_content_type)
        1    0.000    0.000    0.000    0.000 response.py:153(get_buffered)
        1    0.000    0.000    0.000    0.000 publish.py:484(get_time_zone)
        1    0.000    0.000    0.000    0.000 response.py:150(set_buffered)
        1    0.000    0.000    0.000    0.000 :0(len)
        1    0.000    0.000    0.000    0.000 :0(lower)
        1    0.000    0.000    0.000    0.000 :0(get_ident)
        1    0.000    0.000    0.000    0.000 response.py:147(get_compress)
        0    0.000             0.000          profile:0(profiler)

Nothing too surprising here nor is there much fluff. as_bytes (from the Durus package) gets called a number of times as from the same code base QP strives very hard to be a good Unicode citizen in both Python 2.x and 3.0+.

David Binger noted on the QP list today discussion on the python-dev list revolving around pylint being broken in Python 3 and suggests qpcheck.py as a baby pylint alternative.

• Current implementation of qpcheck.py
• Qpy package itself

Running qpcheck.py | grep undefined against the Python 3 standard library returned almost 400 lines, at least some of which are actual errors.

Traversing the URI Path in QP Applications

In order to complete the Songs application we should understand how QP's default traversal mechanism makes it easy to provide a navigable UI for our objects we want to expose to the web.

In the last article in this series we saw through a hello, world example that a QP application has two key classes, a SitePublisher and a SiteDirectory, and that SiteDirectory exposes the root UI of a QP application. Let's flesh out a HTML interface to go along with the REST API offered by the Songs application, to include:

URI segment     Name    Returns to web browser
(export)
-------------------------------------------------------------
class SiteDirectory
/               index   HTML listing of songs
/new            new     HTML form / creation of new song
/delete         clear   HTML form allowing deletion of all songs

The functionality at these URI segments will be provided by SiteDirectory:

class SiteDirectory(Directory):

    def get_exports(self):
        yield ('', 'index', 'Song List', 'This is the root / page of this site.')
        yield ('api', 'api', 'API', 'API documentation and entry point')
        yield ('new', 'new', 'New', 'Add a song to collection')
        yield ('delete', 'clear', 'Delete', 'Delete all songs from collection')

    def index:xml(self):
        header('Song Database')
        '<h1>Songs</h1>'
        '<ul>'
        for song in get_song_db().itervalues():
            '<li>%s: <a href="%s/">%s</a></li>' % (
                song.key, song.key, song.title)
        '</ul>'
        footer()

    # ... for the forms examples provided by new/delete
    # read the SongDirectory class at the end of  this article

What of the API? Thanks to content-negotiation capability provided by the Resource subclass of Directory, we could intermingle our API functionality at the same URI as our HTML UI. Emphasis is on the word could because from this point forward, purely for the sake of clarity in this and subsequent articles on this theme, I'm going to risk angering the RESTafarian gods and instead host the entire REST API under the /api/ url segment. To the SiteDirectory class above we'll merely add an attribute and an entry in get_exports():

class SiteDirectory(Directory):

    def get_exports(self):
        yield ('', 'index', 'Song List', 'This is the root / page of this site.')
        yield ('new', 'new', 'New', 'Add a song to collection')
        yield ('delete', 'clear', 'Delete', 'Delete all songs from collection')
        yield ('api', 'api', 'API', 'API documentation and entry point')

    api = SongDatabaseResource()

    # ...

Therefore our API will be accessible via the SongDatabaseResource subclass (first discussed here) of Resource and will expose the following:

URI      method  accept              Return
-------------------------------------------------------------
class SongDatabaseResource
/api/    GET     application/json    json dict of all songs
/api/    DELETE  application/json    json {'result': 'true'} on success
/api/    POST    application/json    json dict of new song data

Architectural style purity aside, there are reasons in the practical world why one might wish to bury an API, even a REST API, behind a mount point as we've done. The busy developer with security (or marketing) concerns might want to only expose the API to authenticated users. Let's do that:

class SongDatabaseResource(Resource):

    def get_resources(self):
        get_publisher().ensure_signed_in()
        yield export('', '__api__') # docs for web browsers
        yield export('', 'dump', method='GET', accept='application/json')
        yield export('', 'new', method='POST', accept='application/json')
        yield export('', 'clear', method='DELETE', accept='application/json')

    # ...

OK, we sketched out the first / of the HTML UI. How do we traverse to individual songs?

class SiteDirectory(Directory):

    def get_exports(self):
        yield ('', 'index', 'Song List', 'This is the root / page of this site.')
        yield ('api', 'api', 'API', 'API documentation and entry point')
        yield ('new', 'new', 'New', 'Add a song to collection')
        yield ('delete', 'clear', 'Delete', 'Delete all songs from collection')

    # ...

    def _q_lookup(self, component):
        try:
            component = int(component)
            song = get_song_db().get(component)
            if song:
                return SongDirectory(song)
        except ValueError:
            # None / an empty '' response being returned from _q_lookup
            # will result in 404 not_found being delivered as the response.
            return None

    api = SongDatabaseResource()

The important mechanism to note here is _q_lookup. The default QP traversal mechanism (which may easily be changed) traverses Directory subclasses looking for callables or objects. One can create arbitrarily complex URI schemes with levels nested many deep, if that turns your crank.

The object traversal approach is a flexible mechanism, quite different than mapping callables or objects to URIs via regular expressions. But one could do that in QP too, if you found a need to. If you need even more flexibility you can override the Directory class _q_traverse method or dive into the Publisher itself.

One benefit of this approach is others who may use these classes generally do not need to concern themselves at all about where in their URI namespace they deploy these UI components.

The attached file: song.qpy, is a QPY template file containing a quick draft of the HTML UI.

This RESTy Songs database example has morphed into something of a QP howto. For those who just want to see the end result, fear not, I see that coming around the bend soon. It is time to tie it all together... tomorrow.

QP doesn't use WSGI itself in the operation of its own built-in web and SCGI servers, but the framework does make it easy to drive QP applications via WSGI if you have a need to. Here's a quick how-to.

Exposing the QP application as a WSGI app is simple. Create a driver file (let's name it runwsgi.py) and place it in your Python path. Myself I prefer to put such files in my QP application's "site" directory.

# this is runwsgi.py
from qp.lib.site import Site
site = Site('songs')
application = site.get_publisher()

You can then run a WSGI server (such as Spawning) from the command line:

% spawn -t 0 -p 8000 qp.sites.songs.runwsgi.application

Or we can extend runwsgi.py to also provide a self-contained WSGI server:

#! /usr/bin/env python
# this is runwsgi.py
from qp.lib.site import Site
site = Site('songs')
application = site.get_publisher()

if __name__ == '__main__':
    from wsgiref.simple_server import make_server
    host, port = site.get_http_address()
    httpd = make_server(host, port, application)
    hp = httpd.socket.getsockname()
    print("Serving HTTP on %s port %d..." % (hp[0], hp[1]))
    try:
        httpd.serve_forever()
    except KeyboardInterrupt:
        print("\nStopping server(s)")
        if site.is_durus_running():
            site.stop_durus()

We can execute this directly; the application will use the same host and port defined in our application's configuration.

% ./runwsgi.py

In this installment we'll take a break from the implementation started in the post previous of a QP and Durus based RESTy song database application loosely following the meme which has arisen from Eric Florenzano's example bare-metal WSGI implementation of same. Today I want to point out some QP features which are useful and perhaps a little unusual.

class SitePublisher(DurusPublisher):

    configuration = dict(
        durus_address=('localhost', 7023),
        http_address=('', 8023),
        )

class SiteDirectory(Directory):

    def get_exports(self):
        # URI segment exported, method name, crumb, title
        yield ('', 'index', 'Home', 'Home page of the site')

    def index(self):
        return 'hello, world.'

% qp -u songs

curl http://localhost:8023/?age=3&name=Mary

from qp.pub.common import get_request

class SiteDirectory(Directory):

    def index:xml(self):

        context = get_request().fields
        '''
        <html>
        <head>
            <title>Hello</title>
        </head>
        <body>
            <ol>
        '''
        for i in range(int(context.get('age', 1))):
            '<li>%(name)s, %(age)s years old</li>' % context
        '''
            </ol>
        </body>
        </html>
        '''

from qp.pub.common import get_publisher, get_user

class SiteDirectory(Directory):

    def get_exports(self):
        # URI segment exported, method name, crumb, title
        yield ('', 'index', 'Home', 'Home page of the site')
        get_publisher().ensure_signed_in()
        yield ('users', 'users', 'Users', 'Pithy title here')
        if get_user().is_admin():
            yield ('secrets', 'top_secret', 'Home', 'Secrets', 'Something intriguing')

    def index(self):
        return 'hello, world.'

    def users(self):
        return 'hello, real user %s' % get_user().id

    def top_secret(self):
        return 'the password is "orange". Sssh!'

There have of late been a number of articles posted to the Pythonosphere describing approaches to delivering a REST-like or RESTful API. In keeping with the meme Eric Florenzano started by posting his bare-metal no-framework WSGI approach, to the growing list I'll add an entry for the QP web framework and Durus object database tag-team.

Eric Florenzano's deliberately minimalist WSGI application illustrating a bare metal WSGI application with RESTful behaviour has drawn out from other Python web application framework communities a number of useful comparisons:

1. Christian Wyglendowski's entry using cherrypy
2. Tim Parkin's restish approach
3. Grok showing real object persistence by Martijn Faasen.
4. A Werkzeug solution also by Tim Parkin.
5. Carlos de la Guardia provides a solution via repoze.bfg, which, like Grok, shows how Zope3 technologies can be used.

I particularly identify with the CherryPy solution because QP's default traversal mechanism feels similar - both use an object publishing metaphor that relies on traversal of classes rather than a routes or url regular expression approach.

QP inherited its traversal approach from its older cousin Quixote, which in turn borrowed the object publishing metaphor from Zope oh so many years ago. Quixote was always a minimalistic framework without strong opinions; QP is a little more opinionated. While you can quite easily break away from QP's intentional affinity for Durus for object persistence, out of the box QP provides user and session handling all backed by the Durus object database. Despite offering much more capability than Quixote by way of the defaults and conventions chosen, QP, QPY (the modern equivalent to Quixote's PTL templating system) and Durus are small enough to be read through in a single sitting with ease.

Martijn's solution (and any Zope-solution by inference) is also somewhat familiar to me because QP's default object persistence method is the Durus Python object database. Durus can best be thought of as a simpler ZODB (and ZEO) work-a-like.

Since Eric's goal was to see how many requests he could churn out of a bare-metal WSGI application, here are some relative numbers on my workstation, an old desktop running FreeBSD on a single CPU single-core. Even on this suboptimal box the QP songs app can respond to several hundred requests per second.

Relative Performance:

%       Application
---     -----------
100     Eric's bare metal WSGI dict-driven example as baseline
58      CherryPy read from dict-driven example, Spawning server
61      QP, read from dict-driven "database" example, QP native server
60      QP, read from Durus persistent object database, QP native server
42      QP, write to Durus persistent object database, QP native server
65      QP, same app/Durus, read, simple WSGI server
50      QP, same app/Durus, read, Spawning server
59      Repoze.bfd, Spawning server, based on numbers published by Carlos
??      Grok, identified by Martijn as being appox. 50% of Eric's app on
        his machine

Certainly in my own experience raw performance has never been an issue thus I doubt I would ever want to trade away a framework I was comfortable with to write bare metal WSGI apps. Following along with the "song" meme, I'll show in the next couple of posts one approach to structuring a QP application, and some background information on QP and Durus.

class Counter(object):

    def __init__(self):
        self.count = 0

    def next(self):
        self.count += 1
        return self.count

class Song(object):

    def __init__(self, title):
        self.key = None
        self.title = title
        self.counter = Counter()

class SongDatabase(dict):

    def __init__(self):
        self.counter = Counter()

    def add(self, song):
        song.key = self.counter.next()
        self[song.key] = song

class SongDatabaseResource(Resource):

    def get_resources(self):
        yield export('', 'dump', method='GET', accept='application/json')
        yield export('', 'new', method='POST', accept='application/json')
        yield export('', 'clear', method='DELETE', accept='application/json')

    def dump(self):
        """
        curl  -X GET -H 'Accept: application/json' http://127.0.0.1:8023/api/
        """
        data = {}
        for song in get_song_db().values():
            data[song.key] = dict(key=song.key,
                               title=song.title,
                               count=song.counter.count)
        return json.dumps(data)

    def clear(self):
        """
        curl  -X DELETE -H 'Accept: application/json' http://127.0.0.1:8023/api/
        """
        songs = get_song_db()
        songs.clear()
        songs.counter = Counter()
        return json.dumps(True)

    def new(self):
        """
        Example:
            curl  -X POST -d '{"title":"Walking Contradiction"}' \
                  -H "Content-type: application/json" \
                  -H 'Accept: application/json' http://127.0.0.1:8023/api/
            Returns:
                {"count": 0, "id": 3, "title": "Walking Contradiction"}
        """
        data = get_request().read_body()
        try:
            data = json.loads(data)
        except ValueError:
            get_publisher().respond(
                "Bad Request", "Malformed json data %r" % data, status=400)
        song = Song(data.get('title'))
        try:
            get_song_db().add(song)
        except ValueError, e:
            get_publisher().respond("Bad Request", str(e), status=400)
        return json.dumps(dict(id=song.key,
                               title=song.title,
                               count=song.counter.count))

from durus.persistent import PersistentObject
from durus.persistent_dict import PersistentDict

# persistent Python object              # regular volatile Python objects
class Counter(PersistentObject):        #   class Counter(object):

    def __init__(self):                 #       def __init__(self):
        self.count = 0                  #           self.count = 0

    def next(self):                     #       def next(self):
        self.count += 1                 #           self.count += 1
        return self.count               #           return self.count

class Song(PersistentObject):           #   class Song(object):

    def __init__(self, title):          #       def __init__(self, title):
        self.key = None                 #           self.key = None
        self.title = title              #           self.title = title
        self.counter = Counter()        #           self.counter = Counter()

class SongDatabase(PersistentDict):     #   class SongDatabase(dict):

    def __init__(self):                 #       def __init__(self):
        PersistentDict.__init__(self)   #           self.counter = Counter()
        self.counter = Counter()
                                        #       def add(self, song):
    def add(self, song):                #           song.key = self.counter.next()
        song.key = self.counter.next()  #           self[song.key] = song
        self[song.key] = song

From the QP mailing list, Wednesday December 3 2008:

Today the MEMS Exchange released updates of 5 software packages: Durus, QP, Qpy, Sancho, and Dulcinea.

You can find details and downloads at the usual location: http://www.mems-exchange.org/software/

These packages require Python 2.4 or higher, and yes, they even work with Python 3.0.

It does seem that perhaps QP 2.1 and friends is among the first if not actually the first web and database development packages available on Python 3.0 which was released today.

(Previously I've written about QP's templating system, Qpy, and a performance increase moving from Python 2.5 to 3.0.)

Stumbling through Python-related posts on Planet Python led me to a curious Python 3.0 discovery.

First I noted phililon wrote Chameleon: byte compiler for ZPT and Genshi ("Fricken fast", apparently), which led me to Google Spitfire (supposed to be even faster - it's certainly very fast on Python 2.5), which led me to Google's implementation of the Genshi bigtable.py benchmark.

As I'm currently beta testing / porting my code base to be compatible with Python 3.0, and never having seen a performance test I didn't want to try or mangle the interpretation of, this naturally led me to check out my choice of web framework QP's default template package Qpy on Python 3.0.

Using the Google adaptation of the Genshi bigtable.py benchmark, I added an entry for QP; the benchmark results for packages which are included in or run on both Python 2.5 and Python 3.0 are interesting (update now including all the packages I have installed, Python 3.0 timing data derived from a run on RC3):

python2.5 test/bigtable.py
Genshi tag builder                 1465.24 ms
Genshi template                     965.37 ms
Genshi text template                579.29 ms
Genshi template + tag builder      1558.15 ms
Mako Template                       250.65 ms
ElementTree                         777.58 ms
Djange template                    1175.98 ms
Spitfire template                   112.41 ms
Spitfire template -O1                61.18 ms
Spitfire template -O2                28.34 ms
Spitfire template -O3                28.43 ms
cStringIO                            44.26 ms
StringIO                            151.16 ms
list concat                          24.10 ms
QPY Template                        136.12 ms

% python3.0 test/bigtable.py
ElementTree                         449.98 ms
StringIO                            152.47 ms
list concat                          22.56 ms
QPY Template                         37.89 ms

Sadly there isn't much to compare Qpy to on py3k at present. Hopefully other web frameworks, including the big ones, are busy at work producing code compatible with Python 2.x and 3.0. My purpose for doing the comparison was to see if Python 3.0 had a material effect on other templating packages, not so much to compare functionality of say Django templates to Qpy as their intended audience and feature set are so very different.

Incidentally the py3k improvement for Qpy represents a 71.3% speed-up for Qpy on Python 3.0rc1 over what was already amply quick on Python 2.5.1. Whatever the difference is, its not unique to Qpy: ElementTree also benefits greatly, turning in a 44.6% better performance.

These timings are done on an old desktop Unix workstation; more modern machines will turn in much better numbers but relatively speaking I believe these improvements will generally hold up.

On David Binger's Macbook Pro:

# py3k  22 ms
# 2.5.1 55 ms
from timeit import Timer
print(Timer('qpy_template()', 'from qpy.example.example2 import
qpy_template').timeit(1000))

Using timeit to get time for qpy_template() call:

25   ms  Python2.5.1 with quote.so
50   ms  Python2.5.1 without quote.so
11.7 ms  Python3.0 with quote.so
44   ms  Python 3.0 without quote.so

Compiled speedup is 25/11.7 = 2.1
Uncompiled speedup is 50/44 = 1.1

David also notes:

When using profile to test template execution, the it looks like we get a speedup from 254 ms to 199 ms per qpy_template() call between Python 2.5.1 and Python 3.0. Nothing in the profile jumps out at me as being responsible for the change. The C code does, though, do some extra work for Python 2 to force the default encoding to be utf8. Maybe that adds up to a significant amount of time.

** Qpy?** The Qpy template model is going to look upside down if your experience or preference is with any of the many code-in-content template packages out there. Here's Qpy-enabled Python source compared to a couple of other templating approaches:

table = [dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7,h=8,i=9,j=10)
      for x in range(1000)]

# Qpy
def qpy_template:xml():
    '<table>'
    for row in table:
        '<tr>'
        for col in row.values():
            '<td>%s</td>' % col
        '</tr>'
    '</table>'

# Genshi
def test_genshi():
    stream =  MarkupTemplate("""
    <table xmlns:py="http://genshi.edgewall.org/">
    <tr py:for="row in table">
    <td py:for="c in row.values()" py:content="c"/>
    </tr>
    </table>""").generate(table=table)
    stream.render('html', strip_whitespace=False)

# Django
def test_django():
    context = DjangoContext({'table': table})
    DjangoTemplate("""
    <table>
    {% for row in table %}
    <tr>{% for col in row.values %}{{ col|escape }}{% endfor %}</tr>
    {% endfor %}
    </table>""").render(context)

Qpy makes writing quote-safe 'templates' as easy as writing Python code itself.

One of these days I'm sure to need a code-in-content solution and for raw performance alone the Cheetah inspired Google Spitfire is sure to be on my list of packages to look at. But I hope that day doesn't come soon as I've grown rather fond of the content-in-code approach of Qpy which allows me to write Python code that looks like Python code.

A version of QP supporting Python 3.0 (and prior Python versions of course) will be released when Python 3.0 soon hits the streets. While doing some testing I created a lighttpd configuration example illustrating setting up a virtual host with SCGI (QP provides http and scgi servers natively) and SSL support:

$ cat server.key server.crt > server.pem

server.modules = ("mod_access",
                  "mod_scgi",
                  "mod_accesslog")

$HTTP["host"] == "www.example.com" {
    $SERVER["socket"] == "0:443" {
        ssl.engine = "enable"
        ssl.pemfile = "/my/ssl/server.pem"
        ssl.ca-file = "/my/ssl/server.crt"
    }
    scgi.server = ( "" =>
        ( "localhost" =>
            ( "host" => "127.0.0.1",
              "port" => 9000,
              "check-local" => "disable",
              # default disable-time is 60 seconds
              "disable-time" => 5 # seconds
            )
        )
    )
}

==================================================
QP web server direct    2.38 [ms] (mean)
lighttpd 1.4.20
lighttpd proxy to QP    2.41 [ms] (mean)
lighttpd SCGI           2.31 [ms] (mean)

APACHE 1.3.41
APACHE 1.3 proxy to QP  3.39 [ms] (mean)
APACHE 1.3 mod_scgi     2.30 [ms] (mean)
==================================================