Python templates – Django and Cheetah

When writing web applications, sooner or later (usually sooner), everybody is going to need a template language. String-interpolation just doesn't cut it. We need a way to write something that is almost all text (or HTML, or XML, or whatever), but with some dynamic pieces thrown in.

Since this need is so universal, and the basic requirements are so easy to describe, many different groups of people have taken it upon themselves to create Yet Another Template Language. As developers, we can join the fray and roll our own, or we can wade through the myriad options available to us to find the one that meets our needs or philosophy. Those who use PHP or ASP pretty much have the choice made for them, since the languages themselves are glorified template processors. Python programmers have a lot more options.

Here I'm just going to focus on the two Python templating languages I have used in real applications: Cheetah and the Django templating engine. (Django, of course, is more than just templates, but the template subsystem can be used independently.) I use and enjoy both of these, but there are significant differences that are worth comparing and contrasting, when deciding which to use for your particular needs. There are other comparisons out there, including one by the Benevolent Dictator for Life himself (though that's a bit out of date and inaccurate). When choosing which to use, you should read as many opinions as you can, then make the decision yourself. Presented here are just my personal thoughts.

Syntax

Both of these languages are plain-text based, rather than XML based or any other format. This means it's easy to use them for creating formats that are not XML or HTML, like text or even code. It also means it's easy to forget to close a tag or to create non-compliant pages, so always be sure to test with HTML-Tidy or something like that.

The two languages are pretty similar in their syntax, and in my humble opinion, they're both pretty ugly.

Django uses {{ and }} to surround variables to be interpolated. These variables can be passed through a "filter" - a specially designed Python function - using a vertical bar |. One additional parameter can be passed to the filter using a colon :. So, for example, to include a floating-point variable, expressed with two digits after the decimal point, you would write something like: {{ myVar|floatformat:2 }}. There is a lot of punctuation there, but you do get used to it.

Cheetah's variable interpretation looks more like how it's done in shell-scripting languages, with a dollar sign $ and optional brackets { and }, so it looks like $myVar or ${myVar}.

They both also allow some logic and flow control. Django has "tags" surrounded by {% and %}. Cheetah has "directives" that start with # and end with either another # or a newline. Cheetah also allows embedding pure Python using ASP-like <% and %>.

Aesthetically, I prefer the dollar signs of Cheetah for variables, but prefer Django's approach to the logic sections. Either way, you'd better do some finger exercises to limber up before typing.

Philosophy

The major philosophical difference between Cheetah and Django templating is the amount of programming power each system makes available in the templates themselves. In some circles, there is a priority placed on separation of content from code, often going so far as to delegate the tasks to different people. According to this philosophy, designers should work on the presentation, writing HTML and so on, and programmers should work on the logic and back-end behavioral aspects. In the real world, this is an impossible division, because the two are often so closely intertwined, and the very existence of template languages is an admission of this fact. A template is, by definition, a mixture of logic and content. The difference is in the extent of this mixture.

Cheetah makes the whole Python interpreter available to the template writer. Django provides a simple set of "tags" and "filters," allowing limited functionality. These can be extended through "custom tags" and "custom filters." According to the Django documentation, this limitation is intentional, and is meant to limit the mixing of logic and content.

In practice, the mixing happens either way. In Cheetah, it is easy to end up with a whole lot of Python code in the middle of your HTML file, which some would consider inappropriate. In Django, it is easy to wind up constructing pieces of HTML in your code files and passing them to the template processor as parameters. On one side, the Python infects the HTML; on the other side, the HTML infects the Python.

Personally, I'm a one-man development team, so I have no problem with mixing logic and content, either philosophically or pragmatically. I find the Cheetah approach leads to less total code required, plus I'm a big believer in the "we're all adults here" approach to programming, so I prefer the power that Cheetah offers. However, I can understand if people want to limit what logic is available in templates, if they are meant to be edited by designers, marketers, or pointy-haired bosses. In that case, Django might make more sense.

What I use

As I said above, I use both. I use the Django templating system when I am working within the framework of Django. Django does allow you to use any templating system you like, but then you lose the power of the built-in generic views and context processors. I use Cheetah when I don't need all the power of the Django framework (the database access layer, URL dispatcher, authentication, etc.).

I have a slight preference for Cheetah, but they're both very useful. I hope this post provides some help for those choosing between the two.