When I first started to learn Python, it was actually so I could learn Django, which I could use at GMTA.

And I did learn Django, and I do occasionally use it while at work. At home, however, I’ve found that I like Aaron Swartz‘ web.py much better.

web.py is a minimalistic web framework. It has a built-in templating system, a database abstraction layer, some general utilities, and that’s about it. It doesn’t come with an administration interface — which I by the way think is a pretty silly idea. (The built-in administration interface, not that web.py doesn’t include it.)

It gets out of my way. It lets me write the code I want to. It comes with the things I don’t want to have to write: database management and templating. Other than that, I’d really like to write the code myself. The smaller a code base, the easier it must be to write the documentation. But this is where the irony kicks in…

Django is well-renowned for having an extensive and wonderful online documentation. Down to the smallest class method, everything seems to be documented in Django. And while web.py does have an API documentation with good examples, the overall documentation seems pretty insufficient. Unless you do read that API, there’s a lot of the nuances with the template system especially, that go lost.

But what is essential is what you can accomplish. With web.py, I’ve been able to write a publishing system in one day. Granted, it needs polishing. And it lacks critical features. But the essential thing — the publishing — is ready. Sure, I could do this in PHP, too, but the code’s prettier, better separated, and it was more fun writing.

Although the URL mapping system is pretty loose and can make way for some really stupid combinations. (It’s basically just a tuple with pairs of values, the first one being the url to match, the next one being the handler). An example:

urls = (
    '/(\d+)', 'number',
    '/(.+)', 'else'
)

This is pretty readable. But I could write it like this:

urls = (
    '/(\d+)',

    'number', '/(.+)',

    'else'
)

All of a sudden, it becomes pretty much less readable. The web.py faq has this to say on the matter:

Why are the urls just one long list?
If they were a dictionary, they wouldn’t be ordered. If it was a list of tuples, then it’d be a lot more typing.

Sure, it would be more typing to have a list of tuples (I don’t think it would be that much, though), but less code is only useful if it doesn’t obscure the code. This liberal urls-scheme can do that, which is unfortunate. [Update 2007-02-08: I fixed it]

Another problem I find with web.py is its own templating system. I don’t mind that Aaron has built his own, and I know that I could just switch to Cheetah if I wanted to, but I decided to try it out anyway. And unless I’ve just made an error — it does happen, you know — it doesn’t seem to allow use of Python’s built-in functions. Case in point: I was trying to check for the length of a list with Python’s len(). (What I was trying to do is achievable in Python without checking for the length, but one thing I learned with PHP is it’s “not right” to just check the variable, when what you really want to do, is check the length. I also find it makes the code clearer, if I explicitly state what I would like to know — Python is all about being explicit, isn’t it?) However, what I got back was a NameException, since “len” wasn’t defined. Okay, it’s true, I didn’t have it in my $def with() — but is that really necessary. Or is web.py just trying to avoid having its users write real Python in the template? (That is a good idea, just wished they would have told me.)

But enough with the ramblings, this is a 0.2 release, after all. And this is a cute little package. As said earlier, it gets out of my way and comes with the minimum necessary requirements. I’ve never been too fond of the idea that you create a class for every page you have, but the POST and GET methods of web.py classes seem to be a good way to make the best of this convention.

Oh well, what more is there to say? It’s a little rough around the edges, but I like it.

And about that publishing system I wrote, I don’t know if I’ll be using it, but it could possibly be one that take over the administration of this blog. It needs a lot of work still, though. But it could be.