mozilla / nunjucks

A powerful templating engine with inheritance, asynchronous control, and more (jinja2 inspired)
https://mozilla.github.io/nunjucks/
BSD 2-Clause "Simplified" License
8.57k stars 639 forks source link

{% set %} performs tuple unpacking in Jinja #73

Open fooby opened 11 years ago

fooby commented 11 years ago

While researching the fix for #68, I discovered that Jinja's {% set %} with multiple variables actually does tuple unpacking, as opposed to nunjucks' multiple assignment.

>>> from jinja2 import Template
>>> t = 'Test {% set x,y = hello %} X is: {{ x }} Y is: {{ y }}'
>>> Template(t).render({'hello': (5, 10)})
u'Test  X is: 5 Y is: 10'
>>> Template(t).render({'hello': [42, 52]})
u'Test  X is: 42 Y is: 52'
>>> Template(t).render({'hello': [42, 52,23]})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27Orig\lib\site-packages\jinja2\environment.py", line 894, in render
    return self.environment.handle_exception(exc_info, True)
  File "<template>", line 1, in top-level template code
ValueError: too many values to unpack
>>> Template(t).render({'hello': 234})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27Orig\lib\site-packages\jinja2\environment.py", line 894, in render
    return self.environment.handle_exception(exc_info, True)
  File "<template>", line 1, in top-level template code
TypeError: 'int' object is not iterable

Do you think it would be a good idea to adopt this behaviour, especially given that we already have unpacking for {% for %}?

If so, I wouldn't mind coming up with a patch when I have time.

jlongster commented 11 years ago

Yeah, I think I misunderstood ninja's behavior. I'd love it if you came up with a PR, thanks!

garygreen commented 9 years ago

Closing this for now as although it is in jinja, I'd consider it more syntax sugar than missing functionality in nunjucks. Would be nice to see a PR for this though if you have the time :-)

carljm commented 9 years ago

@garygreen if a PR would be accepted, why not leave the issue open to reflect that? Closing the issue communicates (to me at least) that no change is desired.

I agree that this isn't necessarily high priority, but I don't see why a PR for it wouldn't be accepted.

garygreen commented 9 years ago

Absolutely, we can leave it open although my reasoning for closing it is because @jlongster mentioned if the OP could create a PR for this and it's been dormant since April 2013. Also only the OP has expressed an interest in this (as far as I can see from other issues as well), so I'm not sure at what point we decide no PR is going to be done so we can close this or do we keep it open forever until it's added? :-)

carljm commented 9 years ago

@garygreen My feeling is that if it's an improvement we'd ideally like to have, but nobody's gotten around to implementing yet, there's no harm in leaving it open indefinitely, and some benefit, because you never know when somebody with an interest in contributing will be perusing the list of issues looking for something to work on. An open issue communicates "contribution welcome here" more effectively.

(This is something I might also get around to a PR for at some point; I've used it before in Jinja.)