Jinja: لا يعمل bool to string filter

جرب (6>0)|... أو أفضل منه ، قيمة منطقية حرفية مثل true|... أو false|...

نعم ، (6>0)|... يعمل. لماذا تم إغلاق تقرير الخطأ هذا؟

لأنه ليس خطأ ، ولكنه ببساطة أولوية المشغل. بدون أقواس ، ربما كان الرمز الخاص بك يعمل على أنه 6 > (0|string) وهو أمر من الواضح أنه لا معنى له ، ولكن في عمليات أخرى مثل 6 > '5'|int يكون الأمر منطقيًا جدًا ، لذلك هذا ليس خطأ أو سلوكًا غير مقصود.

قادمة من عالم Unix / Linux حيث يشير | إلى محدد خط أنابيب وهذا غير متوقع.

أعتقد أنه يجب أن يكون 6 > ('5'|int) بدلاً من ذلك عند الحاجة إلى مثل هذه القوالب.

أنا لا أوافق ، وسيكون هذا أيضًا تغييرًا هائلًا.

هل يمكننا الحصول على تحذير على الأقل؟

حالة الاستخدام في العالم الحقيقي لهذا هو Ansible Templating Java Boolean Properties:
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 سعيدة بذلك ولكن هل تعتقد أنه من الجيد إصدار تحذير عند استخدام > بين int و string في قوالب Jinja؟

يرجى أيضًا مشاركة رأيك حول مرشح |is_empty لاستخدامه بدلاً من |lenght > 0 .

على أي حال ، شكرا لك على ردودك السريعة. أتمنى لك أسبوعًا سعيدًا.

Ansible يمكن أن تضيف هذا. تمامًا كما فعلوا بـ |bool الذي ليس جزءًا من Jinja نفسها أيضًا.

أعلم أن Python سعيدة بذلك ولكن هل تعتقد أنه من الجيد إصدار تحذير عند استخدام> بين int و string في قوالب Jinja؟

لم تختبرها ، لكن من المحتمل أنها فشلت في Python 3 حيث تفشل مثل هذه المقارنات بصوت عالٍ بدلاً من النجاح بصمت بنتيجة عديمة الجدوى إلى حد ما. لا يقوم Jinja بإجراء عمليات التحقق من الكتابة ، لذلك يقوم فقط بتمرير المعاملين إلى Python (لم يتحقق من الكود ، وربما يستدعي operator.gt(a, b) لذلك)

جميل أن أعرف ، شكرا لك.