Compound Thinking

Request/Response objects in TG2 and beyond

One of the things that slowed down the TG2 release recently has been the move to WebOb based Request/Response objects. There was some extra work required to make this happen right away, but I think it was worth it. WebOb provides an new and interesting approach to request/response objects that I hope will catch on around the Python web community. And it was likely that a switch would be inevitable, so we bit the bullet now in order to avoid future API changes.

Why WebOb?

A WSGI server (see www.wsgi.org) itself doesn’t do anything to provide a full featured web request/response object, but providing a simple CGI style “environment dictionary” and a callable for setting response headers. This is almost certainly the “right” way to do things for WSGI itself, because it provides a usable base, and avoids getting into framework specific issues, but there’s certianly room to provide a nicer API for end users than that.

Which is why modern python web frameworks, from Zope, to Django, Pylons, and TurboGears 1/CherryPy all provide users with a more “user friendly” request/response objects. Unfortunately they all implement different request/response objects, and their implementation is part of the “framework” itself so it isn’t easily reusable outside of the framework, and it certainly isn’t usable across frameworks. As I mentioned earlier, WebOb is an attempt by Ian Bicking to change that. The best thing about WebOb is that it is very much a friend of WSGI, not a competitor. It maintains the WSGI environment as the canonical source of data, and just wraps it in a nicer API.

WebOb makes fiddling with headers, cookies, and all that in your app easier. But it also makes writing WSGI middleware much easier. Several pieces of middleware used by TG2 have already been rewritten to use WebOb internally, and the authors report that WebOb has make thier life much easier. And it’s certiainly made their code easier to read and understand.

WebOb WSGI and re-usable components:

Appropriately, given yesterday’s discussion of re-usable components, the WebOb documentation has an interesting example of a commenting middleware component, that shows off how you can make “pure WSGI” components that are entirely framework neutral.

WebOb and the future of Python Web Development:

And it looks a bit like it’s happening, SkunkWeb, Pylons, and TurboGears 2 are adopting WebOb, and there’s been at least some talk about doing something similar in Django, which I think would help make it easier to write libraries that “just work” in multiple frameworks. Of course, we may never settle on one ORM, or one templating language, , but there’s a whole set of libraries that pretty much just need to manipulate the request and response objects and don’t need to interact with the rest of the framework. So, if several of the major frameworks move to WebOb (and WSGI of course) that would make the dream of cross-framework libraries much more of a reality.

I keep saying it, because I think it’s important, Python’s web framework diversity is only a hindrance if we 1) don’t work together, and 2) don’t learn from each other. And given the current crop of framework developers, I don’t see any chance of us not working together and learning from each other.