Personally, I'd like the patch to go in; the support is far easier on the eyes reading wise, and it has the nice side affect of speeding up the access- index access is last in the chain for var resolution, meaning several pricey exceptions/tests occur every access.
Faster resolution, and cleaner to read. On Tue, Jun 05, 2007 at 02:34:42AM -0000, SmileyChris wrote: > > Ticket http://code.djangoproject.com/ticket/3523 has been sitting Comments on the patch/syntax at least; Offhand, test 'for-tag-unpack03' points out some uglyness in the api- {% for key value in items %} {{ key }}:{{ value }}/ {% endfor %} given ((1,2), (3,4)) yields '1:2/3;4' So which is it? Comma delimted, or space? Realize the parser forces args coming in split on whitespace, but I don't see the point in supporting two different delimiters for the 'var names' chunk of the syntax. Prefer ',' personally (easier to pick out, among other things), but one or the other; KISS mainly. Aside from that, {% for pythons,allowed,trailing,comma,is,not,worth,preserving, in items %} ..super happy template crap... {% endfor %} Again, imo, isn't wise. Technically, you can shove in {% for x,,,,,,y in foon %}{% endfor %} So the parsing there (the 'filter(None, ...)' specifically), is too loose imo. Either way, semantics there differ from python; ',' serves as a marker (basically) to tuple'ize the surrounding bits- >>> for x in [(1,),(2,)]:print x (1,) (2,) is different from the rather nifty deref abuse of >>> for x, in [(1,), (2,)]:print x 1 2 Not sure if supporting the trailing comma deref trick is worthwhile; either way patch up the loose commas handling and it's no longer valid syntax, so the issue can be ignored till someone actually pushes for adding the equiv trick into the template syntax. Use itertools.izip also (you don't need the intermediate list, thus don't allocate one). > The ticket itself relies on a change to context.update, which is > probably why it has been delayed but my latest crack at that makes > more sense (http://code.djangoproject.com/ticket/3529). Technically the change in 3529 should support dict.update's "I take either a sequence of len 2 tuples, or a dict" also- meaning if update is going to be made closer to dict behavior, the intermediate dict isn't needed (straight izip in that case). ~harring
pgp8I5QpnzBTx.pgp
Description: PGP signature
