As Mike Vanier has noted (http://www.paulgraham.com/vanlfsp.html), "LFMs [languages for the masses] deliberately restrict the abstractive power of the language, because of the feeling that users 'can't handle' that much power. This means that there is a glass ceiling of abstraction; your designs can only get this abstract and no more." In this context, the Django template language appears to be an LFM. In Mike's nomenclature, embedded Ruby is an LFSP (language for smart people).
It may be that an LFM is the right design decision in some contexts. For others, an LFSP is better. For my purposes (and please forgive the pretension), I prefer an LFSP. And, while you can use an LFM in Rails (e.g., the Liquid template language), I don't see how you can use an LFSP in Django---at least, because of whitespace, not the LFSP called Python.
Well, it doesn't just appear to be an LFM, it was explicitly designed as such.
I don't think that the Python syntax is an inappropriate choice to be used as a fully enabled template language - you could bolt on <% end %> tags with a preprocessor that indents automatically pretty trivially. Such a template language just doesn't exist yet.
It may be that an LFM is the right design decision in some contexts. For others, an LFSP is better. For my purposes (and please forgive the pretension), I prefer an LFSP. And, while you can use an LFM in Rails (e.g., the Liquid template language), I don't see how you can use an LFSP in Django---at least, because of whitespace, not the LFSP called Python.