Jinja: bool a filtro de cadena no funciona

pruebe (6>0)|... o incluso mejor, un booleano literal como true|... o false|...

Sí, (6>0)|... funciona. ¿Por qué está cerrado este informe de error?

Porque no es un error, sino simplemente una precedencia de operadores. Sin paréntesis, su código probablemente se estaba ejecutando como 6 > (0|string) lo que obviamente no tiene sentido, pero en otras operaciones como 6 > '5'|int tiene mucho sentido, por lo que no se trata de un error ni de un comportamiento no deseado.

Viniendo del mundo de Unix/Linux donde | denota un delimitador de tubería, esto es inesperado.

Creo que debería ser 6 > ('5'|int) en su lugar cuando se necesitan tales moldes.

No estoy de acuerdo, y esto también sería un cambio radical.

¿Podemos tener una advertencia al menos?

El caso de uso del mundo real para esto es Ansible plantillas de propiedades booleanas de Java:
isEnabled={{ some_var | length > 0 | string | lower }}
porque quiero isEnabled=true/false en lugar de isEnabled=True/False .

Eso sería más legible como isEnabled={{ ((some_var | length) > 0) | string | lower }} (al menos para mí), que creo que funcionaría como se esperaba.

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

Más legible y mucho más claro lo que hace.

Bueno, veo que lo leemos de manera diferente y Jinja actualmente lo lee como lo haces tú. Pero la peor parte del ejemplo anterior que no funciona es que siempre da False en silencio.

Sé que Python está contento con eso, pero ¿crees que es una buena idea emitir una advertencia al usar > entre int y string en las plantillas de Jinja?

También comparta su opinión sobre un filtro |is_empty para usar en lugar de |lenght > 0 .

De todos modos, gracias por sus rápidas respuestas. Que tengas una buena semana.

Ansible puede agregar esto. Tal como lo hicieron con |bool que tampoco es parte de Jinja.

Sé que Python está contento con eso, pero ¿crees que es una buena idea emitir una advertencia al usar > entre int y string en las plantillas de Jinja?

No lo he probado, pero probablemente falle en Python 3, donde tales comparaciones fallan rotundamente en lugar de tener éxito en silencio con un resultado un tanto inútil. Jinja no realiza verificaciones de tipo, por lo que simplemente pasa los dos operandos a Python (no revisó el código, probablemente llame a operator.gt(a, b) para ello)

Es bueno saberlo, gracias.