Jinja2 Final aka Jinjavitus Released
The fiinal version of the Jinja2 Django-inspired template engine was just released. It comes with tons of improvements over the older Jinja1 engine and breaks backwards compatibility to some point over the old Jinja1 engine. It’s packaged as a separate package so that you can use both right next to each other for an easier transition.
Compared to Jinja1 it provides tons of new features:
- Dynamic inheritance. It’s now possible to use dynamic inheritance which means that the name of the master template expanded at render time. This makes it easy to switch between different designs.
- Improved macro and import system. Macros can be called with keyword arguments now, are much more lightweight and got their own import system which makes templates easier to understand. The import syntax follows the Python one with small adjustments.
- Heavily improved for-loops. Loops can be filtered now and the length is calculated lazily. This makes it possible to iterate over generators with an unknown length in a much more efficient way.
- Improved behavior of undefined values. Jinja1 had a very silent undefined behavior. If a variable was undefined you were able to call it without getting errors or access any attribute. Jinja2 ships three undefined types that make it easier to debug templates. The default undefined types allows you to print the undefined variables (which when printed outputs nothing) and loop over it (works like iterating over an empty list). However every other operatation raises an UndefinedError. Additionally there an undefined type with the same behavior but it prints the name of the variable or attribute missing if it’s printed. The third builtin undefined type is the strict type which doesn’t allow any operation except of testing if it’s undefined which is the closest you can get to the default Python behavior.
- Improved sandbox. The sandboxed environment if enabled is now easier to use and more secure. In the default configuration everything starting with an underscore is considered insecure so it’s not needed any longer to mark those attributes explicitly. It’s also a lot faster now and easily modifyable by subclassing.
- Line statements. Jinja2 allows to to specify a line statement prefix that marks a whole line as statement. This concept is inspired from Mako and Cheetah and allows very clean templates in many situations. If a line starts with the prefix character (for example “#”), everything up to the end of the line is handled as block.
- Easier API. The API is much easier to use now on nearly every level. The loaders got refactored so that you only have to provide a single methods, filters and tests are normal Python functions now.
- Automatic escaping. Jinja2 comes with optional automatic escaping compatible to Pylons and Genshi
- Improved i18n support. Jinja2 integrates into Babel now which makes internationalizing web applications a charm.
- Extension interface. Jinja2 provides a documented interface that can be used to extend the template engine. The interface could even be used to create Jinja inspired template engines on top of the existing compiler interface with a completely different syntax.
Get it while it’s hot from the Cheeseshop (or PyPI for those of you who prefer the new name).
Awesome work Armin. Jinja’s a damn fine beast.
Comment by Jared — Friday, July 18th, 2008 @ 12:02 amThis is going to be great template to use!
Comment by James — Friday, July 18th, 2008 @ 4:44 amI think you forgot about the main feature/improvement in your blog post, which was initially also the reason for rewriting. It’s a bit faster now and will enable better optimations later :)
But anyway, many thanks for releasing, we already upgraded. And nice holiday.
Regards,
Comment by Christoph Hack — Saturday, July 19th, 2008 @ 7:02 amChristoph
Thanks much Armin!
But I think that the django-inspired features in jinja2 are still less than in jinja1 so why call it django-inspired? :)
Anyway, keep up that good work!
Regards,
Comment by Christopher Grebs — Saturday, July 19th, 2008 @ 10:58 amChristopher
Great stuff…however, I got the following when trying to update to the latest egg on my WinXP box…probably due to _speedups.c
easy_install -U Jinja2
Comment by Jon — Monday, July 21st, 2008 @ 1:08 pm…
Downloading http://pypi.python.org/packages/source/J/Jinja2/Jinja2-2.0.tar.gz#md5=19fe3ee10ee94a6003c53374112f2403
Processing Jinja2-2.0.tar.gz
Running Jinja2-2.0\setup.py -q bdist_egg –dist-dir c:\docume~1\jon~1\locals~1\temp\easy_install-whi05h\Jinja2-2.0\egg-dist-tmp-ndsr6y
warning: no files found matching ‘Makefile’
warning: no files found matching ‘ez_setup.py’
warning: no previously-included files matching ‘*’ found under directory ‘docs\_build\doctrees’
error: Setup script exited with error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin installed,
you can try compiling with MingW32, by passing “-c mingw32″ to setup.py.
Just ran some profiling on Jinja2 against Genshi. Turns out it’s way faster for use with twisted.web, at least 4 times faster on 60 parallel requests. Is this possible or did I do something wrong in my test?
Comment by Vasil — Monday, July 21st, 2008 @ 7:28 pmI had both engines load from filesystem and had auto_reload set to False on both.
@5: I haven’t had the time yet to create windows eggs for it. I’ll try to do that before going on vacation. That should “fix” the problem. As workaround you can explicitly disable the extension with “python setup.py –without-speedups”.
@6: No, that sounds like a reasonable result. There is actually a “real worldish” benchmark of the raw template engine throughput in the rwbench folder. There the results are even more diverting but the template is biased.
Comment by Armin Ronacher — Tuesday, July 22nd, 2008 @ 8:09 amI’m having fun playing with this on my Ubuntu host. But on Win32 (sans VC++ compiler), when I try “setup.py –without-speedups install”, I get this at the end…
…
creating build\bdist.win32\egg\EGG-INFO
removing Jinja2.egg-info\native_libs.txt
copying Jinja2.egg-info\PKG-INFO -> build\bdist.win32\egg\EGG-INFO
copying Jinja2.egg-info\SOURCES.txt -> build\bdist.win32\egg\EGG-INFO
copying Jinja2.egg-info\dependency_links.txt -> build\bdist.win32\egg\EGG-INFO
copying Jinja2.egg-info\entry_points.txt -> build\bdist.win32\egg\EGG-INFO
error: can’t copy ‘Jinja2.egg-info\native_libs.txt’: doesn’t exist or not a regular file
It looks like it’s forgetting to automatically rebuild the file “native_libs.txt”. Perhaps something amiss with how bdist_egg is called? Sadly, I lack the distutils-fu necessary to get past this point.
Comment by Sproaticus — Tuesday, August 19th, 2008 @ 1:30 am@8: I’ll look into that. But if you are using the setup.py directly that should work :-/
Comment by Armin Ronacher — Tuesday, August 19th, 2008 @ 12:16 pmI’m using the setup.py straight from the 2.0 tarball. (I wonder if having make.exe and other dev tools in my PATH isn’t confusing distutils? I have several C compilers, just not the VC++ 7.1. that ActiveState used for their Python build.)
Anyway. On the theory that merely referencing a c sourcefile is causing distutils to look for a compiled binary, I got it to work last night by modifying the setup.py to ignore _speedups.c:
features={
’speedups’: Feature(”optional C speed-enhancements”,
standard=True,
ext_modules=[
# Extension(’jinja2._speedups’, [’jinja2/_speedups.c’]) # changed here
]
)
},
…followed by “setup.py –without-speedups install”
Comment by Sproaticus — Tuesday, August 19th, 2008 @ 2:40 pm