39
will probably go away, the decision to bundle one template engine and use that will
not.
Template engines are like programming languages and each of those engines has a
certain understanding about how things work. On the surface they all work the same:
you tell the engine to evaluate a template with a set of variables and take the return
value as string.
But that’s about where similarities end. Jinja2 for example has an extensive filter sys-
tem, a certain way to do template inheritance, support for reusable blocks (macros)
that can be used from inside templates and also from Python code, uses Unicode for
all operations, supports iterative template rendering, configurable syntax and more.
Onthe other hand an engine like Genshi is based on XML streamevaluation, template
inheritance by taking the availability of XPath into account and more. Mako on the
other hand treats templates similar to Python modules.
When it comes to connecting a template engine with an application or framework
there is more than just rendering templates. For instance, Flask uses Jinja2’s extensive
autoescaping support. Also it provides ways to access macros from Jinja2 templates.
Atemplate abstraction layer that would not take the unique features of the template
engines away is ascienceonits own and atoolarge undertaking for amicroframework
like Flask.
Furthermore extensions can then easily depend on one template language being
present. You can easily use your own templating language, but an extension could
still depend on Jinja itself.
22.4 Micro with Dependencies
Why does Flask call itself a microframework and yet it depends on two libraries
(namely Werkzeug and Jinja2). Why shouldn’t it? If we look over to the Ruby side of
web development there we have a protocol very similar to WSGI. Just that it’s called
Rack there, but besides that it looks very much like a WSGI rendition for Ruby. But
nearly all applications in Ruby land do not work with Rack directly, but on top of a
library with the same name. This Rack library has two equivalents in Python: WebOb
(formerly Paste) and Werkzeug. Paste is still around but from my understanding it’s
sort of deprecated in favour of WebOb. The development of WebOb and Werkzeug
started side by side with similar ideas in mind: be a good implementationof WSGI for
other applications to take advantage.
Flask is a framework that takes advantage of the work already done by Werkzeug to
properly interface WSGI (which can be a complex task at times). Thanks to recent
developments in the Python package infrastructure, packages with dependencies are
no longer an issue and there are very few reasons against having libraries that depend
on others.
239