Opened 15 years ago

Closed 15 years ago

#11824 closed (wontfix)

{% with %} tag to support tuples

Reported by: Ilya Semenov Owned by: nobody
Component: Template system Version: 1.1
Severity: Keywords: with, tuple
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently, that's possible to iterate over a collection of tuples with:

{% for x, y in points %}
    There is a point at {{ x }},{{ y }}
{% endfor %}

However, given a single tuple, there's no way to extract its items to (temporary) context variables. For example:

{% with object.get_last_point as point %}
    There is a point at {{ point.0 }},{{ point.1 }} -- ugly and unmaintainable
{% endwith %}

I would like to propose the extension of {% with %} tag to support the following syntax:

{% with object.get_last_point as x, y %}
    There is a point at {{ x }},{{ y }}
{% endwith %}

Change History (3)

comment:1 by Deepak, 15 years ago


Beautification is not idea behind with tag. Suggested tag doesn't match with Python with tag.

comment:2 by Ilya Semenov, 15 years ago

That's true, the Python's with statement doesn't support that syntax. Moreover, there is no statement in Python which would do that. In order to unpack a tuple in Python, one would do that manually:

x, y = point

Trying to mimic the Python syntax, we would invent a new tag like:

{% with object.get_last_point as point %}
    {% unzip point to x, y %}
    There is a point at {{ x }},{{ y }}
{% endwith %}

or even (which is less imperative and more declarative):

{% with object.get_last_point as point %}
    {% unzip point as x, y %}
        There is a point at {{ x }},{{ y }}
    {% endunzip %}
{% endwith %}

I think my original suggestion is better. It does solve the (I believe not so infrequent) problem, it is backward compatible, and, in my personal opinion, the syntax is quite logical and even makes sense when read as an English language statement.

Your observation makes perfect sense, though, so that's up to the commiters to decide which of the solutions would be more Django-way.

comment:3 by Deepak, 15 years ago

Resolution: wontfix
Status: newclosed

@semenov its better proposal, I'd recommend you to discuss it on django-dev mailing list and then create a new proposal ticket.

Note: See TracTickets for help on using tickets.
Back to Top