And then there was one... more.

Yes, another web ‘framework’ for Python. Get over it!

The folks over at mems-exchange released yesterday two new packages, QP and Qpy. Given the on-going discussion regarding Python web frameworks, the release of QP is bound to re-ignite the too many frameworks debate once again. I happen to disagree with that notion myself – diversity is good and good work done by different people is bound to move the whole state of the art forward. It may be that Quixote’s installed base was already big enough to slow innovation; I wonder what those behind QP have in mind for future iterations?

From the QP package home page

This is QP, a package for defining and running multiple web applications based on Durus for persistence, standard persistent Session and User classes, easy interactive database sessions, qpy for assembling html, and Quixote2-style forms and path traversal. QP makes it easier than ever to use these tools together.

From the Qpy package home page and README

Qpy provides a convenient mechanism for generating safely-quoted html text from python code. It does this by implementing a quoted-string data type and a modification of the python compiler. (This main idea comes from Quixote’s htmltext/PTL.)

The quoted-string class is named “h8”. The h8 class is a subclass of unicode, and similarly represents sequences of characters. The main distinction is that h8 instances represent strings that need no further quoting for use in html documents. When an h8 instance is combined with an ordinary string with an operator like ”+” or ”%”, an html-quoting function is applied to make sure that the result is an h8 instance for which no more quoting is needed.

Now that’s exciting. I’ve been converting a Quixote application over to use nothing but unicode internally and I must say its been more work than I expected. Anything that aids in writing applications that can be expected to behave safely with unicode is a plus for me.

First blush: once installed, getting a new application outline up and running, with its persistent data store (including sessions and user data stores), is dirt simple. After reading the QP source I can see that any Quixote-familiar developer will have an easy time adopting the framework, although imports and module names are quite different so some period of familiarization will be required.

QP’s focus on Durus as a data store suggests developers who have to write for different storage back ends may prefer to continue down the straight Quixote path, although for the additional Unicode support alone, I am tempted myself to look at a mixed approach – take QP’s Durus-centric view for users and sessions and anything else that suits Durus well, and use SQL stores only when it makes sense or is required, much like Zope does.