

Django Book 1.0 online - nickb
http://www.djangobook.com/en/1.0/

======
mhartl
Python was the first language I ever loved. And I've defended it, and
especially its whitespace for block structure, more times than I can count.
(One Perl programmer I know can't mention Python without describing it as
"that whitespace language", and I couldn't understand why until I saw some of
his, ahem, "creatively indented" Perl code. I'm so anal about indentation that
I really never noticed.)

But eventually I realized that whitespace is an Achilles heel in one context:
using Python as an HTML-embedded template language---unfortunately, a very
important case. Seeing this Django book, and finally understanding how they
solved the template-language problem with Python, appears to confirm this
intuition. They solve it the same way all Python frameworks solve it: they
introduce a separate, template-specific language.

This is one big reason why I love Ruby, and Rails. Because Ruby uses an "end"
keyword, it works great as an HTML-embedded language. This means that, in
Rails, you _always_ have a full-strength language at your disposal, and never
have to use a watered-down template language.

It's possible that Django is awesome nonetheless---it does seem to be
attracting some first-rate hackers---and I could certainly be convinced to
switch, but being able to use embedded Ruby will keep me firmly in the Rails
camp for the time being.

~~~
adrianh
Not using/allowing Python code in HTML templates is a deliberate Django design
decision. We created Django in an environment where the designers didn't know
Python (or much programming, in general), and it was much simpler to explain a
simple template language than to teach them Python.

Aside from that, there are some nice benefits to having a separate template
language. One benefit is the extra level of security -- a designer can't bring
the entire site down by making a syntax error in the template. And there's the
benefit that it encourages you (rather firmly!) to separate logic and
presentation. In my Django applications, I'm never tempted to give templates
any logic that isn't strictly presentation-related.

Then there's stuff like the template system's automatic HTML-escaping, which
we just introduced in the Django development version. Sure, I guess you could
do that with a pure-Python-syntax template system, but it seems like you'd end
up hacking things substantially to get that to work.

And, finally, if you don't care for Django's template language, you don't have
to use it. The whole framework is just Python, after all -- import whatever
external libraries you want to import.

~~~
mhartl
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.

~~~
reitzensteinm
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.

~~~
mhartl
Read the quote again: that's the canonical definition of an LFM. It's a
language that restricts the user's power, not by accident, but _by design_.

~~~
reitzensteinm
Sorry, I meant that the authors themselves say that it's designed as one -
i.e. there's no 'appears to be' about it.

But not only was I unclear, in hindsight it was a total nitpick to boot. :)

~~~
mhartl
Ah. Gotcha. Sorry for the misunderstanding.

------
ivankirigin
The collaborative way this book was made is quite impressive. More books
should be wikis or blogs in their infancy.

------
downer
That color scheme _still_ has got to go. Django needs a design that at least
_approaches_ reasonable aesthetic sensibility.

