On Fri, Mar 5, 2010 at 2:54 PM, Jonathan S <jonathan.slend...@gmail.com> wrote:
> 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 %}
>
Yes, that's how python scoping works, however as I specifically noted
there's no reason we can't spill variable names to ensure that the
semantics remain unchanged.
> (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.
>
I haven't given a ton of thought to this but if
settings.TEMPLATE_DEBUG we can insert debug markers into the source
(before each node starts rendering set an attribute about hte current
tag int he template is being rendered) then if an exception is raised
we can combine this bookkeeping data with the existing node structure.
> (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.
>
The versions of those templates I did benchmarks on both omitted
whitespace, they were completely equivalent as far as I can tell.
> (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
>
Variable lookups become calls to the runtime, no reason to reinvent
the semantics.
> (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.
>
>
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
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.
