Jinja: bool à filtre de chaîne ne fonctionne pas

essayez (6>0)|... ou encore mieux, un booléen littéral tel que true|... ou false|...

Oui, (6>0)|... fonctionne. Pourquoi ce rapport de bogue est-il fermé ?

Parce que ce n'est pas un bogue, mais simplement la priorité des opérateurs. Sans parenthèses, votre code s'exécutait probablement sous la forme 6 > (0|string) , ce qui n'a évidemment aucun sens, mais dans d'autres opérations telles que 6 > '5'|int , cela a beaucoup de sens, donc ce n'est ni un bogue ni un comportement involontaire.

Venant du monde Unix/Linux où | désigne un délimiteur de pipeline, c'est inattendu.

Je pense que cela devrait être 6 > ('5'|int) la place lorsque vous avez besoin de tels moulages.

Je ne suis pas d'accord, et ce serait aussi un changement radical.

Pouvons-nous avoir au moins un avertissement ?

Le cas d'utilisation réel pour cela est les propriétés booléennes Java de modèles Ansible :
isEnabled={{ some_var | length > 0 | string | lower }}
parce que je veux isEnabled=true/false au lieu de isEnabled=True/False .

Ce serait plus lisible comme isEnabled={{ ((some_var | length) > 0) | string | lower }} (du moins pour moi), ce qui, je pense, fonctionnerait comme prévu.

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

Plus lisible et beaucoup plus clair ce qu'il fait

Eh bien, je vois que nous le lisons différemment et Jinja le lit actuellement comme vous le faites. Mais le pire de l'exemple ci-dessus qui ne fonctionne pas est qu'il donne toujours silencieusement False .

Je sais que Python est satisfait de cela, mais pensez-vous que c'est une bonne idée d'émettre un avertissement lors de l'utilisation > entre int et string dans les modèles Jinja ?

Veuillez également partager votre opinion sur un filtre |is_empty à utiliser à la place de |lenght > 0 .

En tout cas merci pour vos réponses rapides. Bonne semaine.

Ansible peut ajouter ceci. Tout comme ils l'ont fait avec |bool qui ne fait pas non plus partie de Jinja lui-même.

Je sais que Python est satisfait de cela, mais pensez-vous que c'est une bonne idée d'émettre un avertissement lors de l'utilisation de > entre int et string dans les modèles Jinja ?

Je ne l'ai pas testé, mais il échoue probablement dans Python 3 où de telles comparaisons échouent bruyamment au lieu de réussir silencieusement avec un résultat quelque peu inutile. Jinja ne fait pas de vérification de type, donc il passe juste les deux opérandes à Python (n'a pas vérifié le code, il appelle probablement operator.gt(a, b) pour cela)

Bon à savoir, merci.