Jinja: 2.9 एक लूप के अंदर एक चर निर्दिष्ट करते समय प्रतिगमन

जबकि वर्तमान व्यवहार गलत है, पुराना व्यवहार भी निश्चित रूप से गलत है। {% set %} टैग का उद्देश्य कभी भी बाहरी क्षेत्रों को ओवरराइड करना नहीं था। मुझे आश्चर्य है कि कुछ मामलों में ऐसा हुआ। सुनिश्चित नहीं है कि यहाँ क्या करना है।

जो व्यवहार मैं मानूंगा वह सही था [-1:0] [-1:1] [-1:2] [-1:3] [-1:4] -1 जैसा आउटपुट है।

इस विशिष्ट मामले में मैंने इसे groupby का उपयोग करने के लिए इसे फिर से लिखकर हल किया।

मुझे लगता है कि यह कुछ हद तक सामान्य उपयोग का मामला है - एक लूप में {% set found = true %} जैसे सामान और फिर बाद में इसकी जांच करना। यह निश्चित रूप से लोगों के लिए चीजों को तोड़ने की संभावना है जब यह काम करना बंद कर देता है ...

मैं हैरान हूं कि यह पहले काम करता था। क्या यह हमेशा काम करता था?

जाहिरा तौर पर हाँ:

>>> import jinja2
>>> jinja2.__version__
'2.0'
>>> jinja2.Template('{% for x in range(5) %}[{{ a }}:{% set a = x %}{{ a }}] {% endfor %}{{ a }}').render()
u'[:0] [0:1] [1:2] [2:3] [3:4] '

महान। क्योंकि यहां मुद्दा यह है कि यह बिल्कुल सही नहीं है। इसे किस चर को ओवरराइड करना चाहिए? क्या होगा यदि बीच में कोई फ़ंक्शन स्कोप है। उदाहरण: मैक्रो या ऐसा कुछ। मुझे नहीं पता कि अब इसका समर्थन कैसे करूं।

हम्म शायद पाइथन के स्कोपिंग के समान nonlocal का उपयोग नहीं किया गया था)? यानी बाहरी दायरे में परिभाषित किसी चीज़ को ओवरराइड करने की अनुमति न दें (यानी यदि बीच में कोई मैक्रो है) लेकिन इसे अन्य तरीके से ओवरराइड करने की अनुमति दें?

जाहिरा तौर पर इससे पहले एक टेम्पलेट अभिकथन त्रुटि के साथ पकड़ा गया था:

>>> Template('{% set x = 0 %}{% for y in [1, 2, 3] recursive %}{{ x }}{% set x = y %}{% endfor %}').render()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
jinja2.exceptions.TemplateAssertionError: It's not possible to set and access variables derived from an outer scope! (affects: x (line 1)

व्यवहार रिकर्सिव के साथ/बिना अलग प्रतीत होता है (2.8.1 मुझे रिकर्सिव के साथ अनबाउंडलोकल एरर त्रुटि देता है और बिना '012')

अनबाउंड स्थानीय त्रुटि को मास्टर पर हल किया जाना चाहिए।

मुझे यकीन नहीं है कि यहां कैसे आगे बढ़ना है। मैं वास्तव में नापसंद करता हूं कि इस तरह का काम करना स्पष्ट रूप से संभव था।

पिछले परिवर्तनों के साथ मैं इसे "इच्छित के अनुसार काम करता है" के रूप में बंद करने जा रहा हूं। अगर इससे और कोई नतीजा निकलता है तो हम फिर से विकल्पों की जांच कर सकते हैं।

इस मुद्दे पर भेजा गया (#656 देखें) इस परिवर्तन के बाद मेरे ब्लॉग टेम्पलेट को v.2.8.1 से v2.9.4 में अपग्रेड करने पर उड़ा दिया गया।

लूप पुनरावृत्ति के बीच डेटा के विभिन्न टुकड़े बदल रहे थे, तो मैं इसे ट्रैक रखने के लिए उपयोग कर रहा था। मैं इसे ठीक करने में सक्षम था क्योंकि मैंने मूल टेम्पलेट कोड लिखा था (देखें https://github.com/MinchinWeb/seafoam/commit/8eb760816a06e4f0382816f82586204d1e7734fd और https://github.com/MinchinWeb/seafoam/commit/89d555dbd6a2f256471d2694e4184f2) संदेह है कि मैं अन्यथा करने में सक्षम होता। नए कोड का पालन करना कठिन है क्योंकि तुलना अब ऑनलाइन की जाती है। उदाहरण के लिए, मेरा पुराना कोड (v.2.8.1):

{%- set last_day = None -%}

{% for article in dates %}
    {# ... #}
    <div class="archives-date">
        {%- if last_day != article.date.day %}
            {{ article.date | strftime('%a %-d') }}
        {% else -%}
            &mdash;
        {%- endif -%}
    </div>
    {%- set last_day = article.date.day %}
{% endfor %}

और नया कोड, इन-लाइन तुलनाओं के साथ (v2.9.4):

{% for article in dates %}
    {# ... #}
    <div class="archives-date">
        {%- if ((article.date.day == dates[loop.index0 - 1].date.day) and
                (article.date.month == dates[loop.index0 - 1].date.month) and 
                (article.date.year == dates[loop.index0 - 1].date.year)) %}
                    &mdash;
        {% else -%}
                    {{ article.date | strftime('%a %-d') }}
        {%- endif -%}
    </div>
{% endfor %}

तो मैं सिर्फ यह कहना चाहता था कि "सुविधा" (या "हैक", यदि आप चाहें) का उपयोग किया जाता है और पहले से ही छूट जाता है।

यदि स्कोपिंग मुद्दे इस समय समझदारी से समझने के लिए बहुत जटिल हैं, तो क्या कुछ (कम से कम) चेंजलॉग में जोड़ा जा सकता है ताकि यह कम लोगों को अनजान काट सके?

मुझे नहीं पता था कि यह इतना व्यापक रूप से दुरुपयोग किया गया है: -/कष्टप्रद रूप से इस काम को किसी भी विश्वसनीय तरीके से करने का कोई तरीका नहीं है। हालाँकि मुझे आश्चर्य है कि क्या हम यहाँ सामान्य उपयोग के मामलों को अलग कर सकते हैं और एक अच्छा एपीआई पेश कर सकते हैं।

विशेष रूप से शायद हम कुछ इस तरह जोड़ना चाहते हैं ( loop.changed_from_last ):

{% for article in dates %}
    <div class="archives-date">
        {%- if loop.changed_from_last(article.date.day) %}
            {{ article.date | strftime('%a %-d') }}
        {% else -%}
            &mdash;
        {%- endif -%}
    </div>
{% endfor %}

changed_from_last अच्छा लगता है - कम से कम कार्यक्षमता-वार, नाम ही थोड़ा अजीब आईएमओ है। शायद सिर्फ changed पर्याप्त स्पष्ट होगा?

मुझे लगता है कि पहला तत्व हमेशा "परिवर्तित" माना जाएगा चाहे वह कुछ भी हो? अगर वह व्यवहार किसी के लिए ठीक नहीं है तो वे हमेशा not loop.first चेक जोड़ सकते हैं।

हो सकता है कि previous_context में यह तय करने की कोशिश करने के बजाय कि उपयोगकर्ता इसके साथ क्या करेंगे, यह केवल पिछले पूरे संदर्भ को रखता है।

बस previous या prev ? "संदर्भ" इस संदर्भ में भ्रमित करने वाला लगता है (कोई इरादा नहीं है)

..... और अब मैं पहले से ही कल्पना कर सकता हूं कि कोई next मांग रहा है:/

या शायद बाहरी दायरे में लिखने के लिए एक स्पष्ट बयान: set_outer या कुछ और।

मैं यह सोच रहा था:

class LoopContextBase(object):

    def __init__(self, recurse=None, depth0=0):
        ...
        self._last_iteration = missing

    def changed(self, *value):
        if self._last_iteration != value:
            self._last_iteration = value
            return True
        return False

@davidism हम पूरे स्कोपिंग सिस्टम को तोड़े बिना set_outer नहीं कर सकते। यह मुख्य रूप से पूरी बात को खराब कर देगा।

हाँ, लगा कि ऐसा ही होगा। मैं अनुमान लगा रहा हूं "क्या होगा यदि मैं जानना चाहता हूं कि वर्तमान मूल्य पिछले से अधिक है", या कुछ इसी तरह। लेकिन मुझे changed विधि भी पसंद है।

एक अतिरिक्त डेटा बिंदु के रूप में, यह एक ऐसे मामले के लिए मेरे पैरों पर गिर गया जहां मुझे जेनरेट किए गए एचटीएमएल में एक विशेष वर्ग को इंजेक्ट करने की आवश्यकता है, लेकिन केवल पुनरावृत्त सूची के पहले तत्व के लिए जिसमें कुछ विशिष्ट संपत्ति सेट भी नहीं है । मैं पुनरावृत्त डेटा को संशोधित नहीं कर सकता। मैं loop.first उपयोग नहीं कर सकता (जितना मुझे पसंद है) या अंतिम तत्व से किसी भी चीज़ की तुलना मज़बूती से करने के लिए जो मुझे यहाँ करने की आवश्यकता है, जिसके कारण बुरे निर्माण के साथ प्रयोग किया गया जो पूरी तरह से काम करता था (और यह मेरे लिए स्पष्ट नहीं था कि यह वास्तव में मैं एक बग का दुरुपयोग कर रहा था)।

इसके अतिरिक्त मैं तीसरे पक्ष के प्लगइन्स के माध्यम से विस्तार क्षमताओं की पेशकश करता हूं और पुलिस के पास कोई रास्ता नहीं है कि लेखक अपने टेम्पलेट्स की संरचना कैसे करते हैं, जिससे जिंजा 2.9+ के अपडेट के बाद अंतिम उपयोगकर्ताओं के लिए अचानक टूटना होता है। मैंने अपने कार्यक्रम में अब नवीनतम 2.8 संस्करण पिन किया है ताकि उस मामले में पीछे की ओर संगत बने रहें (जैसा कि मेरी संस्करण योजना वादा करती है), जब तक कि मैं लेखकों को अपने टेम्पलेट अपडेट करने का कोई तरीका नहीं ढूंढ पाता।

क्या कोई कृपया स्पष्ट कर सकता है कि क्यों जिन्जा 2 स्कोप ठीक उसी तरह काम नहीं कर सकते जैसे कि अजगर काम करता है? यानी, jinja2 टेम्प्लेट अजगर मॉड्यूल से मेल खाते हैं, मैक्रोज़ फ़ंक्शन के अनुरूप होते हैं (और उनका अपना दायरा होता है), क्योंकि लूप का अपना दायरा नहीं होता है और आगे भी। जबकि @mitsuhiko का कहना है कि jinja 2.8 और नीचे में बहुत सारे स्कोपिंग बग थे, मेरे लिए यह समझना अधिक सहज था कि स्कोपिंग कैसे काम करती है।

पायथन प्रोग्रामर के लिए, पहली पोस्ट (जिंजा 2.8) से व्यवहार स्पष्ट है। वही https://github.com/pallets/jinja/issues/660 पर लागू होता है, मुझे समझ में नहीं आता कि पाइथन लाइब्रेरी को जावास्क्रिप्ट व्यवहार क्यों लागू करना चाहिए (मैं समझता हूं कि डिफ़ॉल्ट तर्कों का पाइथन का संचालन आदर्श नहीं है, लेकिन किसी भी पायथन डेवलपर को पता है इसके)।

वैकल्पिक रूप से, एक दस्तावेज़ होना चाहिए जो बताता है कि जिंजा में स्कोपिंग कैसे काम करती है ताकि हमें अनुमान न लगाना पड़े।

इसके अलावा कृपया मेरी टिप्पणी को नकारात्मक रूप से न लें, मैं जिन्जा के लिए बहुत आभारी हूं।

@roganov इस पर कुछ नोट्स:

क्या कोई कृपया स्पष्ट कर सकता है कि क्यों जिन्जा 2 स्कोप ठीक उसी तरह काम नहीं कर सकते जैसे कि अजगर काम करता है

क्योंकि पाइथन का दायरा मेरी राय में वास्तव में खराब है, खासकर टेम्पलेट्स में क्योंकि आप आसानी से महत्वपूर्ण जानकारी को गलती से ओवरराइड कर सकते हैं।

जबकि @mitsuhiko का कहना है कि jinja 2.8 और नीचे में बहुत सारे स्कोपिंग बग थे, मेरे लिए यह समझना अधिक सहज था कि स्कोपिंग कैसे काम करती है।

ध्यान दें कि यह एक बग के कारण अपवाद था और यह केवल कुछ सीमित स्थितियों में और पूरी तरह से दुर्घटना से काम करता था। जिंजा के पास हमेशा एक ही दस्तावेज स्कोपिंग नियम थे और इस व्यवहार को कभी भी दस्तावेज

वैकल्पिक रूप से, एक दस्तावेज़ होना चाहिए जो बताता है कि जिंजा में स्कोपिंग कैसे काम करती है ताकि हमें अनुमान न लगाना पड़े।

मैंने इसके लिए कुछ दिन पहले ही दस्तावेज़ों में सुधार किया है

क्या होगा यदि एक चर को लूप में स्पष्ट रूप से पास करने का कोई तरीका था? शायद इस तरह वाक्यविन्यास (पाठ फ़िल्टर से उधार लेना):

{%- set last_day = None -%}

{% for article in dates | pass_variable ( last_day ) %}
    {# ... #}
    <div class="archives-date">
        {%- if last_day != article.date.day -%}
            {{ article.date | strftime('%a %-d') }}
        {%- else %}
            &mdash;
        {% endif -%}
    </div>
    {%- set last_day = article.date.day %}
{% endfor %}

या scoped समान कुछ करने का कोई तरीका है क्योंकि यह वर्तमान में मैक्रोज़ पर लागू होता है?

एक अन्य उपयोग का मामला लूप के बीच किसी प्रकार का काउंटर बनाए रखना होगा। उदाहरण के लिए, कुल कितनी पंक्तियाँ हैं? कितनी पंक्तियाँ कुछ मानदंडों को पूरा करती हैं? चयनित पंक्तियों के लिए कुल कुछ संपत्ति (कुल पंक्ति मुद्रित करने के लिए)?

फ़िल्टर सिंटैक्स यहाँ संभव नहीं होगा क्योंकि पुनरावर्तनीय पर फ़िल्टर पहले से ही संभव हैं।

इसके लिए एक संभावित वाक्यविन्यास जो बुरा नहीं लगेगा वह यह हो सकता है:

{% for article in dates with last_day %}

खासकर जब से with पहले से ही जिंजा में सामान स्कोपिंग करता है, उदाहरण के लिए {% with %} रूप में उपयोग किया जाता है। ओटीओएच, यहां यह विपरीत होगा क्योंकि ब्लॉक एक नया दायरा खोलते हैं, बाहरी दायरे को सुलभ नहीं बनाते हैं ..

यकीन नहीं होता कि यह एक ऐसी सुविधा है जिसकी जिन्जा को जरूरत है या नहीं।

कोई सिंटैक्स इसे नहीं बदलेगा क्योंकि यह अभी भी स्कोपिंग नियमों को बदल देगा। आप वर्तमान संकलन या आईडी ट्रैकिंग सिस्टम के साथ ऐसा नहीं कर सकते। यहां तक ​​​​कि अगर यह उस साधारण मामले के लिए काम करता है, तो क्या होगा यदि किसी के पास लूप है जो recursive । क्या होगा यदि कोई मैक्रो को लूप में परिभाषित करता है। क्या होगा यदि लूप में कॉल ब्लॉक दिखाई देता है।

मुझे लगता है कि यह एक वैश्विक वस्तु को पेश करने के लिए और अधिक समझ में आता है जो स्टोरेज नेमस्पेस के रूप में कार्य करता है और फिर इसे संशोधित किया जा सकता है। जैसे:

{% set foo = namespace() %}
{% set foo.iterated = false %}
{% for item in seq %}
  {% set foo.iterated = true %}
{% endfor %}

हालांकि इसे मौलिक रूप से बदलने के लिए set टैग की आवश्यकता होगी।

@mitsuhiko और उस तरह का पैटर्न पहले से ही do टैग के साथ प्रयोग में है: http://stackoverflow.com/a/4880398/400617

एफडब्ल्यूआईडब्ल्यू, do साथ समाधान बेहद भयानक है। ठीक उसी तरह जैसे लोग पायथन 2 में उपयोग करते हैं जब उन्हें nonlocal ...

मैं पूरी तरह से सहमत हूं, बस यह इंगित कर रहा हूं कि यह वहां है। और जैसा कि एलेक्स ने बताया, इनमें से बहुत सी समस्याओं को फिर से लिखा जा सकता है, या तो फिल्टर के साथ या कुछ तर्क को पायथन में डालकर।

एक और (बदसूरत) हैक एक सूची, परिशिष्ट और पॉप का उपयोग करना है: http://stackoverflow.com/a/32700975/4276230

नमस्ते, मैं लगभग 2 वर्षों से इस कोड का उपयोग कर रहा हूं, अब यह टूट जाता है और नए दस्तावेज से और इस चर्चा से मुझे नहीं लगता कि मैं यहां जो करने की कोशिश कर रहा हूं उसे करने का कोई और तरीका है। यदि नहीं तो कृपया मुझे सुधारें।

{% set list = "" %}
{% for name in names %}
{% if name.last is defined %}
{% set list = list + name.last + " " %}
{% if loop.last %}
{{ list.split(' ')|unique }}
{% endfor %}

@ पूजन14

{{ names|map(attribute="last")|select|unique }}

यद्यपि unique एक अंतर्निहित फ़िल्टर नहीं है, आप हमेशा एक और फ़िल्टर जोड़ सकते हैं जो पूरी चीज़ करता है, क्योंकि आप पहले से ही unique फ़िल्टर जोड़ रहे हैं।

नमस्ते,
मैं समझता हूं कि इसके कारण बहुत सारे "बदसूरत" उदाहरण हैं, लेकिन क्या आप कृपया सलाह दे सकते हैं कि जिंजा टेम्पलेट में लूप के लिए एक चर को सुरुचिपूर्ण/सही तरीके से कैसे बढ़ाया जाए? क्योंकि मेरा कोड भी टूट गया है।

आपको इसे बिल्कुल करने की ज़रूरत क्यों है? इसके अलावा, कृपया अपना कोड शामिल करें।

{% for state in states.sensor -%}
{% if loop.first %}
{% set devnum = 0 %}
{% endif -%}
{%- if state.state == "online" %}
{% set devnum = devnum + 1 %}
{%- endif -%}
{% if loop.last %}
{{ devnum }}
{% endif -%}
{%- endfor -%}

क्या आप कृपया सलाह दे सकते हैं कि जिंजा टेम्पलेट में लूप के लिए एक चर को सुरुचिपूर्ण/सही तरीके से कैसे बढ़ाया जाए?

आपको यह बिल्कुल भी नहीं करना चाहिए था (या करने में सक्षम होना)। तो जवाब है ऐसा मत करो। हालांकि हम इस बात में रुचि रखते हैं कि टेम्पलेट लेखकों को ऐसा करने की आवश्यकता क्यों है।

जिंजा पहले से ही लूप की गणना करता है। {{ loop.index0 }}

@davidism मुझे केवल उन लोगों की आवश्यकता है जो एक शर्त को पूरा करते हैं

एक फ़िल्टर लिखें जो devnum, sensor टुपल्स को ठीक उसी तरह से उत्पन्न करता है जिस तरह से आपको उनकी आवश्यकता होती है। या इसे पायथन में गणना करें और इसे टेम्पलेट में पास करें। या नीचे दिए गए उदाहरण का उपयोग करें। यह मेरे द्वारा देखे गए हर दूसरे उदाहरण के लिए जाता है।

@ मोलोडैक्स आप यह कर सकते हैं:

{{ states.sensor|selectattr('state', 'equalto', 'online')|sum }}

क्या आपका मतलब |count ?

क्षमा करें हाँ, गिनें।

@ मित्सुहिको , आपके समर्थन के लिए धन्यवाद, दुर्भाग्य से, यह काम नहीं करता है।
शायद, jinja2 (फ़िल्टर) को एक प्रोजेक्ट में कुछ सीमाओं के साथ लागू किया गया है जो ( होम असिस्टेंट ) का उपयोग करता है। लेकिन इसने मेरे द्वारा पहले प्रदान किए गए कोड के साथ काम किया। दया।

हाय दोस्तों। आप उदाहरण कोड मांग रहे हैं जो 2.8 के तहत काम करता है, तो यहां मेरा है:

{% set count = 0 %}
{% if 'anchors' in group_names %}
nameserver 127.0.0.1
{% set count = count+1 %}
{% endif %}
{% for resolver in resolvers %}
{% if count < 3 %}
{% if resolver|ipv6 and ansible_default_ipv6.address is defined %}
nameserver {{ resolver }}
{% set count = count+1 %}
{% elif resolver|ipv4 and ansible_default_ipv4.address is defined %}
nameserver {{ resolver }}
{% set count = count+1 %}
{% endif %}
{% endif %}
{% endfor %}

मुझे नहीं पता कि मैं इसे वैश्विक "गिनती" चर के बिना कैसे करूँगा जिसे मैं 2 अलग-अलग लूपों में संदर्भित कर सकता हूं। क्या आपके पास कोई सुझाव है जो इसे 2.8 और 2.9 दोनों के तहत काम करने की अनुमति देगा?

@davidism आपका समाधान बहुत अच्छा है लेकिन मैं इसे हासिल करने की कोशिश कर रहा हूं।
निम्नलिखित के रूप में 2 सूचियां बनाएं

{% set list1 = name|default()|map(attribute="last")|select|list %}
{% set list2 = name|default()|map(attribute="age")|select|list %}

और फिर उन्हें सूची 3 में विलय करें, जो निम्नलिखित की तरह दिखना चाहिए और अंत में सूची 3 पर अद्वितीय (उत्तरदायी फ़िल्टर) लागू करना चाहिए
अंतिम 1-आयु1
last2-age2
अंतिम3-आयु3
अंतिम4-आयु4
अंतिम5-आयु5
अंतिम6-आयु6

मैंने जो नक्शा इकट्ठा किया है वह कई विशेषताओं के साथ काम नहीं करता है #554
मैं ansible के माध्यम से jinja2 का उपयोग कर रहा हूं और इसलिए पहले से ही अजगर में कुछ करना मेरे लिए एक अच्छा विचार नहीं है।

@ pujan14 @aabdnn @Molodax क्या यह पैटर्न आधिकारिक Ansible दस्तावेज़ीकरण से आया है, या यह कुछ ऐसा है जिसे आप लेकर आए हैं या कहीं और पाए गए हैं? किसी भी तरह से, Ansible को इसकी रिपोर्ट करना आसान हो सकता है, क्योंकि वे समझते हैं कि उनके उत्पाद का उपयोग कैसे किया जाना चाहिए और संभवतः अधिक प्रासंगिक समाधान के साथ आ सकते हैं।

@davidism मैंने ऊपर जो टेम्प्लेट प्रस्तुत किया है, वह किसी भी उत्तरदायी दस्तावेज से नहीं आया है। Ansible विशेष रूप से Jinja2 का दस्तावेजीकरण नहीं करता है। मैंने अभी-अभी Jinja2 दस्तावेज़ों को पढ़कर इस टेम्पलेट को स्वयं बनाया है, और यह काम कर गया, इसलिए मैंने इसे उत्पादन में डाल दिया। मैंने मान लिया कि Jinja2 ने वैरिएबल को ग्लोबल बना दिया है।

यदि यह आधिकारिक तौर पर प्रलेखित नहीं है तो मैं इसे बंद करने के इच्छुक हूं क्योंकि यह मूल रूप से था। मैं दोहराता हूँ कि Ansible इस संबंध में आपकी और मदद करने में सक्षम हो सकता है।

@ डेविडिज्म मैंने नए जिंजा 2.9 में लूप के साथ खेला ।
यहाँ एक उदाहरण है।

{% for name in names %}
{% if loop.first %}
{% set list = "" %}
{% endif %}
{% if name.first is defined and name.last is defined and not name.disabled %}
{% set list = list + name.first|string + "-" + name.last|string %}
{% if loop.last %}
{% for item in list.split(' ')|unique %}
{{ item }}
{% endfor %}
{% else %}
{% set list = list + " " %}{% endif %}
{% endif %}
{% endfor %}

ऐसा करने का यह सबसे अच्छा तरीका नहीं हो सकता है, लेकिन यहां मेरी समझ से मैं कोई स्कोपिंग नियम नहीं तोड़ रहा हूं।

2.8 और बेहतर में यह मुद्दा था

यहाँ एक परीक्षण मामला जाता है:

import unittest
from jinja2 import Template

TEMPLATE1 = """{% set a = 1 %}{% for i in items %}{{a}},{% set a = a + 1 %}{% endfor %}"""

class TestTemplate(unittest.TestCase):

  def test_increment(self):
    items = xrange(1,10)
    expected='%s,' % ','.join([str(i) for i in items])
    t = Template(TEMPLATE1)
    result = t.render(items=items)
    self.assertEqual(expected,result)

unittest.main()

इसके बजाय loop.index उपयोग करें।

मुझे लगता है कि loop ऑब्जेक्ट की विशेषता के माध्यम से पिछले लूप वैल्यू तक पहुंच प्रदान करना इसके लिए एकमात्र अच्छा समाधान है। मैंने अभी हमारी परियोजना में इस स्निपेट की खोज की है जिसे केवल यह जांच कर हल नहीं किया जा सकता है कि अंतिम वस्तु वर्तमान से अलग है और ग्रुपबी भी वहां काम नहीं करता है क्योंकि यह कुंजी प्राप्त करने के लिए केवल एक छोटी सी वस्तु/विशेषता पहुंच से अधिक है :

{% set previous_date = none %}
{% for item in entries -%}
    {% set date = item.start_dt.astimezone(tz_object).date() %}
    {% if previous_date and previous_date != date -%}
        ...
    {% endif %}
    {% set previous_date = date %}
{%- endfor %}

हाँ यह एक विचार की तरह लगता है।

लूप ऑब्जेक्ट में set(key, value) और get(key) विधियों को जोड़ने के बारे में क्या? फिर लोग लूप में जो कुछ भी चाहते हैं उसे स्टोर कर सकते हैं।

एक ही विचार था, लेकिन फिर कोई भी गैर-बदसूरत मामला नहीं मिला जहां इसकी आवश्यकता हो। और मैं पहले से ही किसी को setdefault , pop और अन्य तानाशाही जैसी विधियों के लिए पूछ रहा था।

@davidism @ThiefMaster मैं सिर्फ एक स्टोरेज ऑब्जेक्ट उपलब्ध कराने के बारे में सोच रहा था। इस कदर:

{% set ns = namespace() %}
{% set ns.value = 42 %}
...{% set ns.value = 23 %}

स्पष्ट रूप से सेट इस समय विशेषताएँ सेट नहीं कर सकता है लेकिन इसे आसानी से बढ़ाया जा सकता है। चूंकि नामस्थान में कोई पुन: असाइनमेंट नहीं होता है, इसलिए इसे लागू करना काफी सुरक्षित है।

मेरे लिए ठीक लगता है, यह पाइ 2 के लिए nonlocal जैसा ही समाधान है। वैकल्पिक रूप से, स्वचालित रूप से loop.ns , हालांकि यह लूप के बाहर उपलब्ध नहीं होगा।

मुझे नेमस्पेस से जो नापसंद है वह यह है कि {% set obj.attr = 42 %} साथ obj ऐसा करना बहुत लुभावना लगेगा जो namespace() - ऐसा कुछ जो मुझे लगता है कि काम नहीं करना चाहिए .

अन्यथा यह एक दिलचस्प विचार की तरह दिखता है, भले ही मुझे लगता है कि previtem / nextitem / changed() एक नई वस्तु को परिभाषित करने के "शोर" के बिना "सरल" मामलों को अच्छी तरह से कवर करें टेम्पलेट में।

@ThiefMaster यह काम नहीं करेगा। जिस तरह से मैं इस काम को देखूंगा वह यह है कि विशेषता असाइनमेंट पर्यावरण पर कॉलबैक के माध्यम से जाते हैं जो केवल नामस्थान वस्तुओं में संशोधन की अनुमति देगा।

ठीक है, इसलिए कम से कम टेम्पलेट्स का कोई जोखिम नहीं है जिससे उन्हें पारित वस्तुओं पर अप्रत्याशित दुष्प्रभाव हो सकते हैं।

अभी भी उन चीज़ों से थोड़ा सावधान हैं जो लोग कर सकते हैं...

{% macro do_stuff(ns) %}
    {% set ns.foo %}bar{% endset %}
    {% set ns.bar %}foobar{% endset %}
{% endmacro %}

{% set ns = namespace() %}
{{ do_stuff(ns) }}

असल में, मुझे लगता है कि {% namespace ns %} जैसा एक नया ब्लॉक कॉल करने योग्य से एक को परिभाषित करना बेहतर होगा - namespace नामक एक चर एक टेम्पलेट में पारित होने की संभावना नहीं है, और जबकि यह शायद आपको उस टेम्पलेट में नेमस्पेस सुविधा का उपयोग करने से रोक देगा (जैसे पाइथन में एक बिल्टिन को छायांकित करना) यह थोड़ा गंदा लगता है ...

क्या आपके पास इस समस्या का कोई समाधान है या क्या हमें 2.9.6 में प्रीविटम/नेक्स्टिटम की प्रतीक्षा करनी होगी?
मेरे कुछ साल्टस्टैक टेम्प्लेट अब टूट गए हैं।

जैसा कि ऊपर अलग-अलग डिग्री के लिए प्रदर्शित किया गया है, हो सकता है कि आपको वह करने की भी आवश्यकता न हो जो आप कर रहे हैं। अन्यथा, हाँ, यदि आप 2.9.1 का उपयोग करना चाहते हैं तो आपको प्रतीक्षा करने की आवश्यकता है। यह पहले कभी समर्थित नहीं था, यह सिर्फ काम करने के लिए हुआ।

हम पुराने व्यवहार पर वापस नहीं लौटेंगे। जबकि यह साधारण मामलों में काम करता था, यह सही नहीं था और इसे कभी भी समर्थित के रूप में प्रलेखित नहीं किया गया था। जबकि मैं समझता हूं कि यह एक ब्रेकिंग बदलाव है, यह एक फीचर रिलीज (दूसरा नंबर परिवर्तन) में हुआ है, इस तरह हमने हमेशा इन परिवर्तनों को प्रबंधित किया है। यदि आपको पुराने व्यवहार पर निर्भर रहने की आवश्यकता है, तो संस्करण को तब तक पिन करें जब तक कि कोई समाधान जारी न हो जाए।

इसे लॉक कर रहे हैं क्योंकि जो कुछ भी कहा जाना है वह सब कुछ कह दिया गया है। वर्तमान में जिन सुधारों पर विचार किया जा रहा है, उनके लिए #676 और #684 देखें।