Jinja: bool to string 필터가 작동하지 않습니다

(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은 이것을 추가할 수 있습니다. 그들이 Jinja 자체의 일부가 아닌 |bool 했던 것처럼.

나는 파이썬이 그것에 만족한다는 것을 알고 있지만 Jinja 템플릿에서 int와 string 사이에 >를 사용할 때 경고를 발행하는 것이 좋은 생각이라고 생각합니까?

테스트하지는 않았지만 아마도 그런 비교가 다소 쓸모없는 결과로 조용히 성공하는 대신 큰 소리로 실패하는 Python 3에서 실패할 것입니다. Jinja는 유형 검사를 수행하지 않으므로 두 개의 피연산자를 Python에 전달합니다(코드를 검사하지 않았으며 아마도 operator.gt(a, b) 호출).

반갑습니다. 감사합니다.