常见问题

为什么上下文是不可修改的？

当写 contextfunction() 或类似的东西时，你可能会注意到上下文试图阻止 你修改它。如果你已经设法用内部的上下文 API 修改了上下文，你会注意到上下文 上发生的修改在模板中是不可见的。这个的原因是 Jinja 为性能因素，只把上下文 作为模板变量的主要数据源。

如果你想要修改上下文，写一个函数返回一个变量，并用 set 赋值:

{% set comments = get_latest_comments() %}

加速模块是什么和为什么缺失它？

要用在自动转义开启的情况下实现高性能，在老版本的 Jinja2 中转义函数也需要用纯 C 实现，如果 Jinja2 与加速模块一同安装也会使用它。

因为这个特性本身对非模板引擎也很有用，它被移动到 PyPI 上的一个独立的项 目，名为 MarkupSafe 。

Jinja2 不再伴随一个 C 实现而是纯粹的 Python 实现。无论如何，它会检查是否 存在安装好的 MarkupSafe ，如果有，使用 MarkupSafe 的 Markup 类。

所以如果你想加速，只需要导入 MarkupSafe 。

我的回溯看起来很怪异。发生了什么？

如果没有编译调试支持模块并且你在使用一个没有 ctypes 的 Python 安装（ Python 2.4 没有 ctypes ， Jython 或 Google 的 AppEngine ） Jinja2 不能提供 正确的调试信息，且回溯可能是不完整的。这也是为什么现在不能与 Jython 或是 AppEngine 良好工作的原因，没有 ctypes 就不可能使用调试支持扩展。

如果你在 Google Appengine 开发服务器上工作，你可以把 ctypes 模块添加到 白名单来恢复回溯。这无论如何都不能用于生产环境:

import os
if os.environ.get('SERVER_SOFTWARE', '').startswith('Dev'):
    from google.appengine.tools.dev_appserver import HardenedModulesHook
    HardenedModulesHook._WHITE_LIST_C_MODULES += ['_ctypes', 'gestalt']

这个片段的声誉见 Thomas Johansson

为什么没有 Python 2.3 支持？

Python 2.3 中缺少许多在 Jinja2 中大量使用的特性。做出这个艰难的决定是因为使用即 将到来的 Python 2.6 和 3.0 版本，再为老版本 Python 维护代码更加困难。如果你确实 需要 Python 2.3 支持，你可以使用 Jinja 1 或其它仍然支持 2.3 的模板引擎。

我的宏被什么东西给覆盖了

在某些情况下， Jinja 的作用域会是任意的:

layout.tmpl:

{% macro foo() %}LAYOUT{% endmacro %}
{% block body %}{% endblock %}

child.tmpl:

{% extends 'layout.tmpl' %}
{% macro foo() %}CHILD{% endmacro %}
{% block body %}{{ foo() }}{% endblock %}

这在 Jinja2 中会打印 LAYOUT 。这是父模板在子模板之后求值的副作用。 这允许子模板传递信息到父模板。要避免这个问题，重命名父模板中的变量或宏 让它们有不同的前缀。