我必须检查一下，但我认为这应该可行：

<h2>locals()</h2>
<pre>{{ locals() }}</pre>
<h2>globals()</h2>

... https://stackoverflow.com/questions/3398850/how-to-get-a-list-of-current-variables-from-jinja-2-template

@mitsuhiko来自https://stackoverflow.com/a/13757358/188833 ：

import jinja2

@jinja2.contextfunction
def get_context(c):
 return c

app.jinja_env.globals['context'] = get_context
app.jinja_env.globals['callable'] = callable

用于调试，例如，如果视图函数——适当抽象的恕我直言——只返回一个上下文对象（例如 dict、OrderedDict），则 pyramid_debugtoolbar 可以显示模板上下文

• https://github.com/Pylons/pyramid_debugtoolbar
• https://westurner.org/wiki/awesome-python-testing#pyramid

用例

我在这里的用例是将一些参数从 CLI 实用程序传递到 jinja2 模板（我想在模板中定义默认值（例如对于 Dockerfiles（没有autoescape ，所有的东西））

我想做的是

{% set ENVVAR=context.get('ENVVAR', 'DEFAULT') %}

但是，唉，实际的context对象是 [...]

@westurner ，那么它有效吗？ 我现在无法检查它，但在我看来，如果{{ locals() }}包含不可转换的字节，它应该会失败。

• 如果没有自定义 JSONEncoder， json.dumps(locals())将无法工作（例如repr()用于 [code objects,]）
• 也许pprint.pformat(locals()) ？ （这将是一个方便的内置）

• ... autoescape=True然后会阻止 XSS

当扩展第三方应用程序的模板时，这将是一个福音。 我目前正在使用象形文字创建幻灯片，它建立在 sphinx 和 Jinja2 上。

我扩展了默认的象形文字主题，我想知道模板是否包含一些变量，告诉我我是否在幻灯片上。 也许变量在那里，也许不是。 所以我目前正在象形文字源代码中寻找我需要的东西。

能够直接从模板中简单地转储所有可用变量（即，无需修改任何Python 代码）将使这变得更快、更容易。 所以，假设能够做这样的事情会很好：

{% extends "!layout.html %}

{# ... or any other sensible name #}
{% dump_variables() %}

{% block body %}
Hello World!
super()
Goodbye World
{% endblock %}

这样，我可以在开发新主题时反省象形文字为我提供的任何东西。

我为此目的创建了一个扩展，它可以在https://github.com/niwinz/django-jinja/files/1607805/jinja_extensions.py.txt找到

@ShaheedHaque任何屏幕？

如果您打开文件，注释中会有一个输出示例。 如果
需要，我今晚回家时可以提供一个实际的屏幕截图...

2018 年 1 月 6 日 02:23，“anatoly techtonik” [email protected]写道：

@ShaheedHaque https://github.com/shaheedhaque任何屏幕？

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/pallets/jinja/issues/174#issuecomment-355716273或静音
线程
https://github.com/notifications/unsubscribe-auth/AEp7KdBBslHJPIGp5VliuF74bxSZTk-wks5tHtkEgaJpZM4AXefd
.

@ShaheedHaque屏幕与第一篇文章中的 Smarty 输出进行比较会非常好。

按照要求。 您会看到内容是按上下文变量、过滤器和测试组织（和排序）的。 此外，这里是屏幕上的放大视图，其中包含更多“有趣”的上下文变量。 看看 depth=3 的限制如何足以显示一些细节，而不会导致过度嵌套输出的可能性，因为我相信，最需要的事情是确切知道存在哪些（顶级）上下文变量而不是任何结构的全深度：

您还可能会看到更改/扩展所显示内容的细节是微不足道的（或者对于知道解析器如何工作的人来说，这将是微不足道的......我不在那个幸运的圈子里:-)）。

看起来很有用。 那么为什么不填PR呢？

考虑到新代码应该在忍者代码库中的位置提供一些指导，我很乐意这样做（我不熟悉这个项目）。

我也不是，但https://github.com/pallets/jinja/blob/master/jinja2/ext.py似乎是一个好的开始。

参见 PR #798。

将在 2.11 中作为新扩展提供。

谢谢！

调试扩展文档应该提醒用户注意无意
泄露敏感信息
通过{% debug %}标签，如何判断是否扩展
已启用（以便静态分析器可以识别有人忘记
在发布前删除{% debug .* %} 。

983

2019 年 10 月 4 日星期五，David Lord [email protected]写道：

关闭#174。

—
你收到这个是因为你被提到了。
直接回复此电子邮件，在 GitHub 上查看它，或将线程静音。