Jinja: bool to string filter funktioniert nicht

Erstellt am 6. Aug. 2018  ·  14Kommentare  ·  Quelle: pallets/jinja

Erwartetes Verhalten

Das Filtern bool bis string sollte True oder False entsprechend dem Wert ergeben.

Tatsächliches Verhalten

Das Filtern bool bis string ergibt immer False .

Vorlagencode

Paste the template code (ideally a minimal example) that causes the issue

'{{6 > 0}}' ==> True
'{{6 > 0|string}}' ==> False
'{{6 > 0|bool}}' ==> True
'{{6 > 0|bool|string}}' ==> False

Ihre Umgebung

  • Python-Version: 2.7
  • Jinja-Version: Ich kenne die Jinja-Version nicht, Ansible ist 2.5.4

Hilfreichster Kommentar

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

Besser lesbar und viel klarer, was es tut

Alle 14 Kommentare

versuchen Sie es (6>0)|... oder noch besser, einem wörtlichen booleschen Wert wie true|... oder false|...

Ja, (6>0)|... funktioniert. Warum ist dieser Fehlerbericht geschlossen?

Weil es kein Fehler ist, sondern einfach eine Operator-Priorität. Ohne Klammern lief Ihr Code wahrscheinlich als 6 > (0|string) , was offensichtlich keinen Sinn macht, aber in anderen Operationen wie 6 > '5'|int macht es sehr viel Sinn, also ist dies weder ein Fehler noch ein unbeabsichtigtes Verhalten.

Aus der Unix/Linux-Welt kommend, wo | ein Pipeline-Trennzeichen bezeichnet, ist dies unerwartet.

Ich denke, es sollte stattdessen 6 > ('5'|int) sein, wenn solche Besetzungen benötigt werden.

Ich bin anderer Meinung, und dies wäre auch eine massiv bahnbrechende Änderung.

Können wir wenigstens eine Warnung haben?

Ein realer Anwendungsfall dafür ist Ansible, das boolesche Java-Eigenschaften als Vorlage bereitstellt:
isEnabled={{ some_var | length > 0 | string | lower }}
weil ich isEnabled=true/false statt isEnabled=True/False will.

Das wäre besser lesbar als isEnabled={{ ((some_var | length) > 0) | string | lower }} (zumindest für mich), was meiner Meinung nach wie erwartet funktionieren würde.

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

Besser lesbar und viel klarer, was es tut

Nun, ich sehe, wir lesen es anders und Jinja liest es derzeit so wie du. Aber der schlimmste Teil des obigen nicht funktionierenden Beispiels ist, dass es immer stillschweigend False gibt.

Ich weiß, dass Python damit zufrieden ist, aber halten Sie es für eine gute Idee, eine Warnung auszugeben, wenn Sie > zwischen int und string in Jinja-Vorlagen verwenden?

Bitte teilen Sie auch Ihre Meinung zu einem |is_empty -Filter mit, der anstelle von |lenght > 0 verwendet werden kann.

Trotzdem danke für eure schnellen Antworten. Hab eine schöne Woche.

Ansible kann dies hinzufügen. Genau wie sie es mit |bool haben, das auch nicht Teil von Jinja selbst ist.

Ich weiß, dass Python damit zufrieden ist, aber halten Sie es für eine gute Idee, eine Warnung auszugeben, wenn Sie > zwischen int und string in Jinja-Vorlagen verwenden?

Ich habe es nicht getestet, aber wahrscheinlich schlägt es in Python 3 fehl, wo solche Vergleiche lautstark fehlschlagen, anstatt stillschweigend mit einem etwas nutzlosen Ergebnis erfolgreich zu sein. Jinja führt keine Typprüfungen durch, also übergibt es nur die beiden Operanden an Python (hat den Code nicht überprüft, wahrscheinlich ruft es operator.gt(a, b) dafür auf)

Gut zu wissen, danke.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen