Jinja: 布尔到字符串过滤器不起作用

尝试(6>0)|...甚至更好，例如true|...或false|...的文字布尔值

是的， (6>0)|...有效。 为什么这个错误报告被关闭了？

因为它不是错误，而只是运算符优先级。 如果没有括号，您的代码可能以6 > (0|string)的形式运行，这显然没有意义，但在6 > '5'|int等其他操作中它很有意义，因此这既不是错误也不是意外行为。

来自 Unix/Linux 世界，其中|表示管道分隔符，这是出乎意料的。

我认为当需要这样的演员时，它应该是6 > ('5'|int) 。

我不同意，这也将是一个巨大的突破性变化。

我们至少可以发出警告吗？

实际用例是 Ansible 模板化 Java 布尔属性：
isEnabled={{ some_var | length > 0 | string | lower }}
因为我想要isEnabled=true/false而不是isEnabled=True/False 。

这将更具可读性isEnabled={{ ((some_var | length) > 0) | string | lower }} （至少对我而言），我相信它会按预期工作。

{{ (some_var|length > 0) | string | lower }}

更易读，更清楚它的作用

好吧，我看到我们对它的阅读方式不同，而 Jinja 目前和你一样阅读它。 但上述非工作示例中最糟糕的部分是它总是默默地给出False 。

我知道 Python 对此很满意，但是您认为在 Jinja 模板中在int和string >时发出警告是个好主意吗？

另外请分享您对使用|is_empty过滤器而不是|lenght > 0的意见。

无论如何，感谢您的快速回复。 周末愉快。

Ansible 可以添加这个。 就像他们对|bool所做的那样，这也不是 Jinja 本身的一部分。

我知道 Python 对此很满意，但您认为在 Jinja 模板中的 int 和 string 之间使用 > 时发出警告是个好主意吗？

尚未对其进行测试，但它可能在 Python 3 中确实失败了，在这种比较中，这种比较大声失败，而不是默默地成功，结果有点无用。 Jinja 不做类型检查，所以它只是将两个操作数传递给 Python（没有检查代码，可能它为它调用operator.gt(a, b) ）

很高兴知道，谢谢。