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 $の間で$ >を使用する場合は、警告を発行することをお勧めしますか？

また、 |lenght > 0の代わりに使用する|is_emptyフィルターについてのご意見をお聞かせください。

とにかく、迅速な対応ありがとうございます。 良い一週間を。

Ansibleはこれを追加できます。 ジンジャ自体の一部でもない|boolで行ったように。

Pythonがそれに満足していることは知っていますが、Jinjaテンプレートでintとstringの間で>を使用するときに警告を発行するのは良い考えだと思いますか？

テストはしていませんが、Python 3ではおそらく失敗します。Python3では、そのような比較は、やや役に立たない結果で黙って成功するのではなく、大声で失敗します。 Jinjaは型チェックを行わないため、2つのオペランドをPythonに渡すだけです（コードをチェックしなかったため、おそらくoperator.gt(a, b)を呼び出します）

よろしくお願いします。