Just a few thoughts, this is my idea and I'm not an expert at
compilers, so forgive me if I'm somewhere wrong.
(1) For me, personally, I think the scoping of variables should be
kept inside a block.
{% with "x" as x %}
{% with "y" as x %}
{% endwith %}
{{ x }}
- you would print "y", because you don't pop the context, while
the current template engine would print "x" (no? i didn't test it)
{% endwith %}
(2) Another issue will occur during a rendering error. What if a
template tag throws an exception? The traceback will show the trace
through the generated code, instead of the original templates.
(3) You're code snippets in the examples you are giving are not
equivalent. The second omits at least four print statements, and what
is say in (4) below. So, the timing is not really worth that much.
(4) How would you compile {{ a.b }} ? I think this can be interpreted
as either a.b(), a[b], or a.b
Python is typed dynamically. So, everytime you want to read out
{{ i }}, this should be changed to:
var_i = i() if callable(i) else i
(5) Be sure that custom template tags, like {% filter escape %} ... {%
endfilter %} still work. A separate result[], to capture the content
of this tag, and apply the filter, is required.
(6) I think that the code generator / compiler you are planning to
write, will be hard to maintain and hard to debug. Because compilers
need to evaluate several ways of how your source code could be written
in the destination language, it should decide which route will mostly
lead to the fasted path at runtime... The dynamic behavior of python
will make it difficult. Compare that to the very clean template.Node
structure, which is understandable for Django developers.
Correct me if I'm somewhere wrong, but I think that the slowness of
the current Django template engine is caused mostly because of the
pushing/popping of contexts and the expensive Variable.resolve. I
think that precompiling the templates to python code and further into
binary, would at most result in 2x the performance.You're proposing to
change the context behavior, are you planning to change the resolve
method also, in order to improve the performance? That and giving up
on the custom template tags, makes me think this is just another,
maybe better, but not really compatible template language.
At the positive side: some things can be improved by the preprocessor.
{% spaceless %} ... {% endspaceless %} can be executed at runtime.
b.t.w. I wrote a compiler for a Python based template language once.
It worked pretty well, also by compiling the template to python
(*.pyc) binary files. (The project is almost dead now, because I
started using Django now for most of my websites.)
http://code.google.com/p/python-pages/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
