I've been working with Zope now for about nine years. While things have changed for the better by a lot with the introduction of interfaces and Zope 3 views, Zope's various object publishers have continued to make me sad. I like object publishing via graph traversal; it fits my obviously-warped-by-Zope brain. But the complexity of the Zope2 publisher is mindblowing (I recently reimplemented it ... it took about five months to get mostly-right). Zope 3's object publisher is a bit better but I still just don't like it very much. It just seems overcomplicated and slightly too close to Z2's publisher for my tastes.

In the meantime, as part of Repoze , I've been working a good bit with other Python web frameworks. All of them have things I really like. Django has great docs, and a nice view system. Pylons is steadfastly agnostic about how and what you should plug in to it. TurboGears is embracing third-party WSGI components in a big way.

But none of them have object publishing in the same vein as Zope does. Even TurboGears' object publishing story just isn't quite the same as Zope's, as you walk a code graph rather than a model graph. I could probably learn to live with URL-based dispatch ala Routes or Django's URL dispatcher, but I'm not quite sure I'm ready to give up my object-publishing blanket just yet; we also seem to do a lot of work where arbitrary-depth model hierarchies are important. At the same time, I just don't feel like continuing to use Z2 or Z3 is a viable option for me in the long term, mostly due to those frameworks' propensity for feature-creep and complexity. Z2 has been "berry, berry good to me", and Z3 technologies have made things bearable for the last few years, but I can't help feeling like in some way it's just time to move on.

So, for the last few weeks (at the expense of much else), with a lot of help from Paul Everitt and Tres Seaver, I've been working on a new web framework. This framework is named (provisionally) repoze.bfg ("Big Fine Gun"). It uses the Zope CA, and Zope interfaces, and a bunch of other Zope libraries, but doesn't use the Z2 or Z3 publishers; it has its own publisher. It also does not use any form of Zope security; it implements its own security model. It has the same concept of views that Zope and Django have. Its development model is closer to Pylons' or Django's than it is to Zope's. It uses the z3c.pt templating system, which is a reimplementation of ZPT, or you can also use XSL, or plug in whatever templating system you like really. It doesn't assume any particular persistence mechanism; you provide your own (ZODB, relational, filesystem, etc); in a tip of the hat to Pylons, that's considered an application decision. It depends heavily on a variety of Ian Bicking creations, including WebOb and Paste. It's very small, currently clocking in at a little over 2000 lines of code, minus dependencies. That said, it does about what I want out of a web framework.

Yup, the Python web framework field is a crowded one. But then again, I gotta admit don't care very much. I'm not really writing it for you. I'm writing it for me. If its existence confuses you, so be it, sorry. But I am sensitive to starting out right with documentation . I'm trying to be dogged about keeping those docs in sync with the code.

It's still in a pretty early stage, but it has definitely moved its way out of "toy" phase. We've managed to create several applications using the framework so far. The very first one was repoze.virginia , which is the application which serves up Repoze.org these days. It's a simple file hierarchy publisher with slight dynamicism. The second one Paul wrote, and it's named repoze.lxmlgraph , where he demonstrates how one might publish a website that was represented entirely by a single XML document. The third one is named repoze.cluegun , which is a port of Rocky Burt's ClueBin application to repoze.bfg. That code runs the ClueGun website . Of the three, ClueGun is probably the most real-world app (albeit small).

I'm sort of excited about it. It's sort of like getting out of jail or something to be able to have your own web framework to write as you see fit. We'll likely continue to develop applications using repoze.bfg, pushing features into the framework as we find them useful.