Wednesday, December 07, 2005

Turbogears, Django, and Subway

I'm still trying to get my mind into Python web programming. There are three main "pythonic megaframeworks" that I've seen get a lot of press lately, and trying to decide between them is a bit of a puzzle (as it always is in the Python web programming world). All three are seen, to some extent, as Ruby on Rails for Python.



My desire to get into Python web programming has to do with a little app I'm creating for businesses to track the time their employees/consultants spend at work and generate the appropriate payroll reports. So all of the descriptions below will be, to some degree, colored by this goal.

One framework I'm not really considering right now is Zope, partly because it seems to be "unpythonic." It's really a very nice system, especially for distributed teams of content builders. But I'm not such a team. Additionally, I've tried doing things with it before, and it seems powerful, but maybe a little too heavyweight for my current app. On the other hand, it's easy (and cheap) to get a Zope hosting account for your web app, whereas some of the other solutions may require dedicated servers.

Turbogears is the one I'm currently examining most closely. It basically ties together several pre-existing projects: CherryPy, Kid, SQLObject, MochiKit, and FormEncode being some of the major ones. It's coming along nicely, and is currently at version 0.8a5. What I'm really interested in here is the authentication and authorization framework they're adding in version 0.9. Not that it can't be used now; I'd just prefer not to roll my own identity module if possible.

Django is another framework that came out of the woodwork recently. I'm less familiar with it than with the others, though from what I've seen it is the most mature of the three. I mainly shy away from it because it seems that the developers have "reinvented the wheel" a bit. Rather than using some of the existing frameworks like CherryPy, they invented their own. Of course, those "existing frameworks" didn't exist (or weren't mature enough) when Django was started, so that's forgiveable. But I still like the idea of tying together other frameworks in a nice way rather than coding up something new.

Subway was created to directly compete with Rails (down to the name). It shares a lot in common with TurboGears. It integrates CherryPy and SQLObject, but where TurboGears uses Kid, Subway uses Cheetah templates. Subway was my first choice to begin the app (it seems to have appeared first of the three), but it doesn't seem to have the same developer momentum behind it. But it's worth following closely.

So there you have it. TurboGears, Django, and Subway. Each promises to radically simplify web development. The unfortunate thing for a Pythonisito like me is that "there's more than one way to do it." Doesn't sound too Pythonic, does it?

4 comments:

  1. I don't think I can make this meetup (discovered it too late), but I'll definitely try for the next one.

    ReplyDelete
  2. Btw, I actually did look at some of the other pre-full-stack frameworks. Webware, Twisted, CherryPy, Quixote, Cheetah, ZPT, PTL, and more. I followed the PyWebOff blog and everything. What I (and I assume others, as well) were looking for is The One True Way of doing things with web apps. TurboGears is definitely on the way to providing this, and is extremely helpful even at its 0.8a5 release.

    ReplyDelete
  3. Anonymous5:20 AM

    You forgot the most pythonic of them all:
    Pylons!

    www.pylonshq.com

    Not the "NIH"-Syndrome like on Django,
    not the bad design descicions of TG,
    not the.. oh wait, Subway doesnt exist anymore ;)

    ReplyDelete
  4. @anonymous:

    If I had been writing this post today rather than in 2005, I agree that I'd have to mention Pylons. In fact, the title probably would have been Django, Pylons, and TurboGears. When I wrote the post, however, Pylons 0.8 (the oldest milestone I could find on the Pylons trac) was still over 3 months in the future....

    I would be interested in what you consider the bad design decisions of TG, by the way, as I ended up choosing to implement all my projects in it.

    ReplyDelete