[ubernostrum]

Before you go reading hidden motivations into the design of Django's template language, I think you should read Jacob's explanation of his approach to templating:

http://jacobian.org/writing/salt/

Personally, I'm inclined to agree with him, and I take a stance similar to what's expressed in one of the comments there: it's better to leave a potentially-good feature out, but provide the means for people to implement it when they need it, than to burden the language with a potentially-bad feature that's hard to disable.

[jacquesm]

If you have an if, and ifequals and their functions are such that if you need to do a combined if something and something > somethingelse you have to resort to either duplicating a bunch of code or including small fragments of html in order to avoid the duplication severely decreasing readability then your design is simply lacking.

There is an outstanding ticket on adding boolean functionality to the ifequals conditional. The argument that others 'should learn to cook' can be countered with that if you're a cook you should cook what people like to eat, not to dictate your taste to others.

The if, ifequals and other animals in the conditional zoo could be replaced with a single multi purpose and powerful if statement such as listed in the link above.

You either have an if or you don't, if you have one it might as well work.

There is not much 'bad' about an if statement that would be worse than the endless duplication of template code that the current construct forces you to adopt.

This is a problem because any django apps that are going to be released using the more powerful 'if' statement will immediately have an extra dependency.

I have yet to see a single good argument about what would be so dangerous about having a more powerful if statement in the template language.