Jinja: बूल टू स्ट्रिंग फिल्टर काम नहीं करता

(6>0)|... या इससे भी बेहतर कोशिश करें, एक शाब्दिक बूलियन जैसे true|... या false|...

हाँ, (6>0)|... काम करता है। यह बग रिपोर्ट क्यों बंद है?

क्योंकि यह एक बग नहीं है, बल्कि बस ऑपरेटर प्राथमिकता है। कोष्ठक के बिना आपका कोड संभवतः 6 > (0|string) के रूप में चल रहा था, जिसका स्पष्ट रूप से कोई मतलब नहीं है, लेकिन अन्य कार्यों जैसे कि 6 > '5'|int में यह बहुत मायने रखता है, इसलिए यह न तो एक बग है और न ही अनपेक्षित व्यवहार है।

यूनिक्स/लिनक्स दुनिया से आ रहा है जहां | एक पाइपलाइन सीमांकक को दर्शाता है यह अप्रत्याशित है।

मुझे लगता है कि इस तरह के कलाकारों की आवश्यकता होने पर इसके बजाय 6 > ('5'|int) होना चाहिए।

मैं असहमत हूं, और यह भी एक व्यापक रूप से तोड़ने वाला बदलाव होगा।

क्या हमें कम से कम चेतावनी मिल सकती है?

इसके लिए वास्तविक दुनिया का उपयोग-मामला जावा बूलियन गुणों के लिए उत्तरदायी टेम्पलेटिंग है:
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 }}

अधिक पठनीय, और अधिक स्पष्ट यह क्या करता है

ठीक है, मैं देख रहा हूँ कि हम इसे अलग तरह से पढ़ते हैं और जिंजा वर्तमान में इसे वैसे ही पढ़ता है जैसे आप पढ़ते हैं। लेकिन उपरोक्त गैर-कामकाजी उदाहरण का सबसे खराब हिस्सा यह है कि यह हमेशा चुपचाप False देता है।

मुझे पता है कि पायथन इससे खुश है, लेकिन क्या आपको लगता है कि जिन्जा टेम्प्लेट में > के बीच int और string का उपयोग करते समय चेतावनी जारी करना एक अच्छा विचार है?

कृपया $ |lenght > 0 के बजाय उपयोग करने के लिए |is_empty फ़िल्टर पर अपनी राय साझा करें।

वैसे भी, आपकी त्वरित प्रतिक्रियाओं के लिए धन्यवाद। आपका सप्ताह अच्छा हो।

Ansible इसे जोड़ सकते हैं। ठीक वैसे ही जैसे उन्होंने |bool के साथ किया था जो कि जिन्जा का भी हिस्सा नहीं है।

मुझे पता है कि पायथन इससे खुश है लेकिन क्या आपको लगता है कि जिन्जा टेम्पलेट्स में int और string के बीच > का उपयोग करते समय चेतावनी जारी करना एक अच्छा विचार है?

इसका परीक्षण नहीं किया है, लेकिन शायद यह पायथन 3 में विफल हो जाता है जहां इस तरह की तुलना कुछ हद तक बेकार परिणाम के साथ चुपचाप सफल होने के बजाय जोर से विफल हो जाती है। जिंजा टाइप चेक नहीं करता है, इसलिए यह सिर्फ दो ऑपरेंड को पायथन में पास करता है (कोड की जांच नहीं करता है, शायद यह इसके लिए operator.gt(a, b) कहता है)

जानकर अच्छा लगा, धन्यवाद।