On Jun 5, 11:48 pm, Brian Harring <[EMAIL PROTECTED]> wrote:
> 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 %}
Regarding the whole comma/space issue, the patch simply aimed to be
flexible.
Mostly because I didn't want to be a stickler over comma-space-
variable vs comma-variable.
My assumption would be that comma was the "official" and documented
way to do it (as opposed to just space separation), but I didn't think
that forcing an error was necessary. Maybe I was being to sympathetic
to template designers :)
>
> 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-
I'd be against introducing this complexity into the tag. Sure it
differs from Python, but as Russ has said, it's not Python!
Perhaps the tag could be tightened to error if there are extraneous
(or missing?) commas, but that is as far as we should go.
> 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).
I concur, that is a worthy change
Thanks for your thoughts, Brian!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
