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은 재귀가 있는 UnboundLocalError 오류 및 없는 '012')

바인딩되지 않은 로컬 오류는 마스터에서 해결되어야 합니다.

여기서 어떻게 진행해야 할지 잘 모르겠습니다. 나는 분명히 이런 종류의 일을 할 수 있다는 것이 정말 싫습니다.

마지막 변경 사항으로 "의도한 대로 작동함"으로 종료하겠습니다. 이로부터 더 많은 여파가 있다면 우리는 대안을 다시 조사할 수 있습니다.

이 변경 사항으로 인해 v.2.8.1에서 v2.9.4로 업그레이드할 때 내 블로그 템플릿이 폭발한 후 이 문제로 전송되었습니다(#656 참조).

루프 반복 사이에 다양한 데이터 조각이 변경되는 경우 추적을 유지하는 데 사용하고 있었습니다. 원래 템플릿 코드를 작성했기 때문에 고칠 수 있었습니다(https://github.com/MinchinWeb/seafoam/commit/8eb760816a06e4f0382816f82586204d1e7734fd, Ifed464,122649 but1264152deafoam/55db5566d5 참조). 그렇지 않았다면 할 수 있었을까 하는 의심. 비교가 이제 인라인으로 수행되므로 새 코드를 따르기가 더 어렵습니다. 예를 들어, 내 이전 코드(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 %}

그래서 저는 "기능"(또는 원하는 경우 "해킹") 이 사용되었고 이미 누락되었다고 말하고 싶었습니다.

범위 지정 문제가 너무 복잡하여 현시점에서 현명하게 파악할 수 없는 경우 변경 로그에 무언가(최소한)를 추가하여 모르는 사람을 덜

나는 이것이 그렇게 널리 남용된다는 것을 알지 못했습니다 :-/ 짜증나게도 이 작업을 신뢰할 수 있는 방식으로 만들 방법이 없습니다. 그러나 여기에서 일반적인 사용 사례를 분리하고 더 멋진 API를 도입할 수 있는지 궁금합니다.

특히 다음과 같은 것을 추가하고 싶을 수도 있습니다( 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 좋은 것 같습니다. 적어도 기능적으로는 이름 자체가 약간 어색한 IMO입니다. changed 만으로도 충분히 명확할까요?

첫 번째 요소는 그것이 무엇이든 상관없이 항상 "변경된" 것으로 간주될 것이라고 생각합니까? 그 행동이 누군가에게 좋지 않다면 그들은 항상 not loop.first 체크를 추가할 수 있습니다.

아마도 previous_context 는 사용자가 무엇을 할 것인지 결정하지 않고 전체 이전 컨텍스트를 보유합니다.

그냥 previous 또는 prev ? "context"는 이 문맥에서 다소 혼란스럽게 들립니다(말장난 의도 없음)

.....그리고 이제 누군가가 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 (내가 원하는 만큼) 사용하거나 마지막 요소의 어떤 것과도 비교할 수 없어 여기서 해야 할 일을 안정적으로 수행할 수 있습니다. (그리고 그것이 실제로 내가 버그를 남용했다는 사실도 분명하지 않았습니다.)

또한 타사 플러그인을 통해 확장 기능을 제공하고 작성자가 템플릿을 구성하는 방법을 감시할 방법이 없으므로 Jinja 2.9+로 업데이트한 후 최종 사용자에게 갑작스러운 손상이 발생합니다. 작성자가 템플릿을 업데이트할 수 있는 방법을 찾을 때까지 이전 버전과의 호환성을 유지하기 위해 현재 최신 2.8 버전을 프로그램에 고정했습니다.

누군가 jinja2 범위가 파이썬이 작동하는 것처럼 정확하게 작동할 수 없는 이유를 설명해 주시겠습니까? 즉, jinja2 템플릿은 파이썬 모듈에 해당하고, 매크로는 함수에 해당하고(자체 범위가 있음) for 루프에는 자체 범위가 없습니다. @mitsuhiko 는 jinja 2.8 이하가 범위 지정 버그가

파이썬 프로그래머의 경우 첫 번째 게시물(Jinja 2.8)의 동작이 분명합니다. https://github.com/pallets/jinja/issues/660 에도 동일하게 적용됩니다. 파이썬 라이브러리가 자바스크립트 동작을 구현해야 하는 이유를 이해하지 못합니다(파이썬의 기본 인수 처리가 이상적이지 않다는 것을 이해하지만 모든 파이썬 개발자는 알고 있습니다. 그것의).

또는 추측할 필요가 없도록 jinja의 범위 지정이 작동하는 방식을 설명하는 문서가 있어야 합니다.

또한 제 댓글을 부정적으로 받아들이지 말아주세요. 진자에게 정말 감사합니다.

@roganov 이에 대한 몇 가지 참고 사항:

누군가 jinja2 범위가 파이썬이 작동하는 것처럼 정확하게 작동할 수 없는 이유를 명확히 해 주시겠습니까?

내 생각에 Python의 범위 지정은 특히 템플릿에서 매우 나쁩니다. 실수로 중요한 정보를 쉽게 무시할 수 있기 때문입니다.

@mitsuhiko 는 jinja 2.8 이하가 범위 지정 버그가

이것은 버그로 인한 예외였으며 일부 제한된 상황에서만 순전히 우연히 작동했습니다. Jinja는 항상 동일한 문서화된 범위 지정 규칙을 가지고 있었고 이 동작은 문서화 되지 않았습니다 . 항상 변수는 외부 범위로 전파되지 않는다고 합니다. 루프가 끝난 후 변수가 설정되지 않았기 때문에 이것을 쉽게 볼 수 있습니다.

또는 추측할 필요가 없도록 jinja의 범위 지정이 작동하는 방식을 설명하는 문서가 있어야 합니다.

나는 이것을 위해 이미 며칠 전에 문서를 개선했습니다.

변수를 루프에 명시적으로 전달하는 방법이 있다면 어떻게 될까요? 아마도 다음과 같은 구문일 것입니다(텍스트 필터에서 차용).

{%- 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 와 유사한 작업을 수행할 수 있는 방법이 있습니까?

또 다른 사용 사례는 루프 간에 일종의 카운터를 유지하는 것입니다. 예를 들어, 총 행은 몇 개입니까? 몇 개의 행이 일부 기준을 충족합니까? 선택한 행에 대한 일부 속성의 총계(총 행 인쇄)?

필터는 iterable에서 이미 가능하기 때문에 여기에서는 필터 구문이 불가능합니다.

나쁘게 보이지 않는 이에 대한 가능한 구문은 다음과 같을 수 있습니다.

{% for article in dates with last_day %}

특히 with 는 예를 들어 {% with %} 와 같이 사용될 때 Jinja에서 이미 범위 지정 작업을 수행하기 때문에 특히 그렇습니다. OTOH, 블록을 사용하면 새 범위가 열리고 외부 범위 변수에 액세스할 수 없게 되므로 반대가 됩니다.

그것이 Jinja에게 필요한 기능인지 아닌지 확실하지 않습니다.

범위 지정 규칙을 여전히 파괴하기 때문에 구문은 이것을 변경하지 않습니다. 현재 컴파일 또는 ID 추적 시스템에서는 그렇게 할 수 없습니다. 그 간단한 경우에 작동하더라도 recursive for 루프가 있으면 어떻게 됩니까? 누군가 for 루프에서 매크로를 정의하면 어떻게 될까요? for 루프에 호출 블록이 나타나면 어떻게 될까요?

스토리지 네임스페이스 역할을 하고 로 수정할 수 있는 전역 개체를 도입하는 것이 더 합리적이라고 생각합니다. 예:

{% 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

FWIW, do 의 솔루션은 매우 끔찍합니다. 사람들이 nonlocal 가 필요할 때 Python 2에서 사용하는 해결 방법과 마찬가지로 ...

나는 그것이 거기에 있다는 것을 지적하면서 전적으로 동의합니다. 그리고 Alex가 지적한 것처럼 이러한 많은 문제는 필터를 사용하거나 Python에 일부 논리를 추가하여 다시 작성할 수 있습니다.

또 다른 (추한) 해킹은 목록, 추가 및 팝업을 사용하는 것입니다. 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 %}

@pujan14

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

unique 는 기본 제공 필터가 아니지만 이미 unique 필터를 추가하고 있으므로 항상 모든 작업을 수행하는 다른 필터를 추가할 수 있습니다.

안녕하세요,
이로 인해 "추한" 예가 많이 있다는 것을 이해하지만 jinja 템플릿의 for 루프에 있는 변수를 우아하고/올바른 방식으로 증가시키는 방법을 조언해 주시겠습니까? 내 코드도 손상되었기 때문입니다.

왜 그것을 할 필요가 있습니까? 또한 귀하의 코드를 포함하십시오.

{% 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 -%}

우아하고/올바른 방식으로 jinja 템플릿의 for 루프에서 변수를 증가시키는 방법을 조언해 주시겠습니까?

당신은 이것을 전혀 해서는 안 됩니다(또는 할 수 있어야 함). 그래서 대답은 그렇게하지 마십시오. 그러나 우리는 템플릿 작성자가 그렇게 할 필요가 있는 것처럼 보이는 이유에 관심이 있습니다.

Jinja는 이미 루프를 열거합니다. {{ loop.index0 }}

@davidism 조건에

devnum, sensor 튜플을 필요한 방식으로 정확히 생성하는 필터를 작성하십시오. 또는 Python에서 계산하여 템플릿에 전달합니다. 또는 아래의 예를 사용하십시오. 이것은 내가 본 다른 모든 예에 적용됩니다.

@Molodax 당신은

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

|count 를 의미하지 않았습니까?

네, 죄송합니다.

@mitsuhiko ,
아마도 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개의 개별 루프에서 참조할 수 있는 전역 "count" 변수 없이 이 작업을 수행하는 방법을 모르겠습니다. 2.8과 2.9에서 모두 작동하도록 하는 제안 사항이 있습니까?

@davidism 귀하의 솔루션은 훌륭하지만 이를 달성하기 위해 노력하고 있습니다.
다음과 같이 2개의 목록을 만듭니다.

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

그런 다음 list3에 병합합니다. 다음과 같이 표시되어야 하고 마지막으로 list3에 고유(ansible 필터)을 적용해야 합니다.
마지막 1-나이 1
last2-age2
마지막3세3세
마지막 4세 4세
마지막 5세 5세
마지막 6세 6세

내가 수집한 지도에서 여러 속성이 작동하지 않습니다. #554
나는 가능한 것을 통해 jinja2를 사용하고 있으므로 미리 파이썬에서 무언가를 추가하는 것은 나에게 좋은 생각이 아닙니다.

@pujan14 @aabdnn @Molodax 이 패턴은 공식 Ansible 문서에서 가져온 것 입니까 , 아니면 다른 곳에서 생각해 냈거나 찾은 것입니까? 어느 쪽이든 Ansible에 보고하는 것이 더 쉬울 수 있습니다. Ansible은 제품을 어떻게 사용해야 하는지 이해하고 더 관련성 높은 솔루션을 제공할 수 있기 때문입니다.

@davidism 위에서 제시한 템플릿은 Ansible 문서에서 가져온 것이 아닙니다. Ansible은 Jinja2를 구체적으로 문서화하지 않습니다. 방금 Jinja2 문서를 읽고 이 템플릿을 직접 만들었고 작동했기 때문에 프로덕션에 적용했습니다. Jinja2가 변수를 전역으로 만들었다고 가정했습니다.

공식적으로 문서화되지 않은 경우 원래대로 닫는 것이 더 좋습니다. 이와 관련하여 Ansible이 더 많은 도움을 드릴 수 있다는 점을 다시 한 번 말씀드립니다.

@davidism 새로운 jinja 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 개체의 속성을 통해 이전 루프 값에 대한 액세스를 제공하는 것이 이에 대한 유일한 좋은 솔루션이라고 생각합니다. 마지막 개체가 현재 개체와 다른지 확인하는 것만으로는 해결할 수 없는 이 스니펫을 프로젝트에서 발견했습니다. 키를 가져오기 위한 사소한 항목/속성 액세스 이상이기 때문에 groupby도 작동하지 않습니다. :

{% 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 및 기타 dict-like 메소드를 요구하는 누군가를 이미 볼 수 있었습니다.

@davidism @ThiefMaster 저는 저장 객체를 사용할 수 있게 하려고 생각했습니다. 이와 같이:

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

분명히 set은 현재 속성을 설정할 수 없지만 이것은 쉽게 확장될 수 있습니다. 네임스페이스 자체에 대한 재할당이 발생하지 않기 때문에 구현하기에 매우 안전합니다.

나에게 괜찮아 보이지만 Py 2의 nonlocal 와 동일한 솔루션입니다. 또는 루프 외부에서 사용할 수는 없지만 자동으로 loop.ns 설정합니다.

내가 네임스페이스에서 싫어하는 것은 obj 가 namespace() 가 아닌 {% set obj.attr = 42 %} 하고 싶은 유혹을 느낀다는 것입니다. 작동하지 않아야 한다고 생각합니다. .

그렇지 않으면 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의 previtem/nextitem을 기다려야 합니까?
내 saltstack 템플릿 중 일부가 지금 손상되었습니다.

위에서 다양한 정도로 설명했듯이 현재 하고 있는 작업을 수행할 필요가 없을 수도 있습니다. 그렇지 않으면 예, 2.9를 사용하려면 기다려야 합니다. 이전에는 지원되지 않았으며 방금 작동했습니다.

우리는 이전 행동으로 돌아가지 않을 것입니다. 간단한 경우에는 작동했지만 올바르지 않고 지원되는 것으로 문서화되지 않았습니다. 이것이 주요 변경 사항이라는 것을 이해하지만 기능 릴리스(두 번째 숫자 변경)에서 발생했으며, 이는 우리가 항상 이러한 변경 사항을 관리하는 방식입니다. 이전 동작에 계속 의존해야 하는 경우 수정 사항이 릴리스될 때까지 버전을 고정합니다.

말해야 할 모든 것을 말했기 때문에 이것을 잠급니다. 현재 고려 중인 수정 사항은 #676 및 #684를 참조하세요.