Hi,
I would like to participate in this year's Google Summer of Code by
introducing a new backend for the Django (and Jinja2) templating
language.
As the author of Jinja2 I recently decided to rewrite the code
generation
of the engine to better support alternative Python implementations
like
PyPy and restricted environments like Google's Appengine.
The Jinja2 backend is already usable for other templating engines as
well
for as long as the sematics are compatible with the ones from Jinja2.
However with a better backend design the Django semantics should be
possible to implement in there as well.
As such as I am proposing to keep this backend independent of either
Django and Jinja2. I would maintain inside a separate repository and
with
each release of Jinja2 and Django port fixes into their respective
code
bases. This could also be used as a basis for other template engines
or
domain specific languages if necessary.
The reason I don't want to keep this a separate package but actually
copy
the code over to Django and Jinja2 are twofold. First of all I don't
want
to introduce a new dependency for the template engines themselves.
Secondly I really want to keep this an implementation detail for
Jinja2 at
the very least. In Django we don't want to see dependencies either.
Reasons (coming from the current Jinja2 backend) for a new version:
1. implement a drop-in interpreter as alternative to the template
compilation for better error reporting during development.
2. implement an ast.py based compiler in order to avoid the debug
traceback hackery that is currently in place to support debugging
of
templates with accurate line numbers.
3. Better support for jit interpreted Python installations like PyPy
by
removing the need to call locals() or sys._getframe which is
currently
required by Jinja2 in order to implement includes.
4. Python generating compiled for GAE. This one would not have the
same
error handling capabilities as the interpreter and the AST based
compiler, but has the advantage of running everywhere and would
allow
module based importing like the one currently in use in Jinja2.
Reasons why this is interesting for Django:
1. It would greatly speed up execution of core tags. The idea is to
use
code generation for the builtin tags and to generate a context as
necessary when droppping into old-style custom tags.
2. Provide a new API that can be used for new tags that allow code
generation behind the scenes.
3. Better debugging capabilties by providing actual Python tracebacks
for
errors in templates.
How much speedup will we see in Django? Probably not as much as
people
are hoping as Django's current semantics just cannot be sped up to
Jinja2
levels by keeping the extension API unchanged. However because there
are
already some abstractions in place we can probably achieve a
significant
speedup for certain common template types that it reduces the need to
switch to Jinja2.
Why am I proposing this as a GSOC Django project instead of hacking on
this under the umbrella of the PSF for Jinja2 alone? First of all,
speeding up Jinja2 is a boring task right now as it is very close to
raw
Python performance already. Secondly there was a proposal by Alex
last
year and there is already a proposal here about template engine
compilation backends and if I am going to do this for Jinja2 anyways,
I
can keep it generic enough to also support Django.
Regards,
Armin
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
