Schedule A

A few years ago now, Guido van Rossum endorsed Django by saying it was his personal favorite. At the time I had read the docs once and kind of tried it, but something rubbed me the wrong way. There was just too much structure, which for whatever reason didn’t fit what I was trying to do at the time. I didn’t really understand why Guido preferred Django.

About a year ago I started working with Django to make more complicated applications. It so easy I started producing little productivity web apps for my own purposes. I discovered Django was very usable for rapid development, but I still didn’t have the perspective understand how Pythonic Django was.

Currently I am working on a major project in Pylons, a loose framework based on WSGI. This experience has given me something to contrast Django with and now I see why Guido would describe it as Pythonic.

Though it has been mentioned that there is some magic in Django, I find when it comes to the important things Django is very explicit. In contrast to Pylons, Django is explicit in request, response, template context and helpers. In Pylons these objects are treated as global.

A view/controller, which in Django is just a callable instead of having to be a method of a class, receives the request as an explicit argument. The view’s job is to return a response object. Django provides shortcuts to make this as easy as rendering a template, but fundamentally Django takes a request and returns a response. In Pylons these objects are global, which makes concept like what if I call another view/controller while I am render a given view/controller unsettling. It is unclear what magic is going on behind the scenes.

More importantly in Django you have explicitly define the context you are passing into your template in one place. You can create a special context which includes some data from the request, but even this must be done explicitly. In Pylons the context is global and comes with baggage–various pre-defined objects which are handy to have in a template, but not really knowing how they get there makes things feel more magical. It also mean you have to look in many places to see what names are available in the context for a template. The interface between template and view/controller is probably the most important to be clean and clear, especially if you consider that the people writing the templates should probably be distinct from the people writing the code.

Finally sometimes you need to do more complex things in templates, and you need some help. In Pylons help in a template comes from h, which represents a projects lib.helpers module. This is a relatively un-namespaced holding area for every bit of helper code you might want. In contrast Django makes you explicit declare you are adding special template helpers (new tags and filters) to a given template. That means in a given template (or template hierarchy) you can know which helpers you are using. This is a place where Django could be even more explicit and use name space even more name spacing.

Fundamentally all of this plus clearer url dispatch means that Django is both more explicit and more able to handle re-usable apps. Since explicit is better than implicit, that would make Django more Pythonic. Now, I think would agree that Django is my favorite as well.