[jacquesm]

I think part of the resistance here is that rolling this in to trunk would be an admission they got it wrong in the first place.

There is a lot of psychology behind the scenes in open source projects.

In big companies this can express itself as NIH and other symptoms like that, in open source projects it usually means that sooner or later somebody admits they were wrong in the past or that a project will fork or that there will be 'unofficial' patches.

The python absence of a 'switch' statement is another nice example of such an issue.

[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.

[mmorris]

I'm not so sure the problem comes down to a fear of admitting getting it wrong in the first place, as much as it is a desire to hold tightly to a rule for template design that the creators feel has served Django well (keeping the templates simple). When it comes to your own rules, everyone is a little afraid of the dreaded 'slippery slope', no?

For the record, I agree that something this basic should be built in to Django. I certainly use it often, I'd be a bit surprised if its use wasn't common in the Django community.

[jacquesm]

> keeping the templates simple

That's the whole point here, isn't it?

They're keeping the language simple at the expense of making the templates more difficult to read and less efficient.

There is no slipperly slope here, only in the eyes of those who want to present it that way. It's a simple design flaw that has been kept in its place against a fair bit of community pressure.

There are other issues like this, for instance at the ORM level, have a look here for a fine example of that, you won't even have to leave this site:

http://news.ycombinator.com/item?id=523661

If it is broken, and people put up very solid arguments for it being broken the idea is to fix it, not to come up with all kinds of arguments 'why it isn't broken'.

What is broken or not depends on your use case. If you ORM or template language forces people to twist themselves in to all kinds of weird shapes to jump through your hoop you should make life easier for them, even if your personal experience is different. It's a matter of viewpoint, and by playing 'dictator' you are making life harder for others.

[lacker]

The absence of 'switch' seems reasonable - it's pretty rare that you need a switch, so is it really worth introducing another keyword?