Ticket #7817: Extending "with" and "include" tags.

[Łukasz Rekucki]

Hi,

I was wondering if I could get some feedback on this ticket. It was
recently briefly discussed here:
http://groups.google.com/group/django-developers/browse_thread/thread/fb8a4a0eb4e1d35e.
It has a patch with tests and probably not-so-good docs, but still
needs a decision.

I'll gladly reviews some tickets or do any other volunteer labor in
exchange for someone to take a look at this ;)

Best regards,
Lucas Rekucki

[Łukasz Rekucki]

2010/6/30 Łukasz Rekucki <lrek...@gmail.com>:

I would like to bring this up again, because this is something that
would really improve readability of my templates. I'm mainly
interested in ticket #7817 (the include tag changes), but extending
"with" tag (ticket 9456) would keep things consistent.

Best regards,
Łukasz Rekucki

[SmileyChris]

On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
> I would like to bring this up again, because this is something that
> would really improve readability of my templates. I'm mainly
> interested in ticket #7817 (the include tag changes), but extending
> "with" tag (ticket 9456) would keep things consistent.

Here's a link to the ticket for the lazier ones among us:
http://code.djangoproject.com/ticket/7817

The main decision which needs to be made is one of syntax.

The current proposal uses:
{% include "name_snippet.html" with name="Joe" greeting="Hello" %}
but this introduces an inconsistency with the {% with %} tag.

Consistency would be nice, but I think this starts to look a bit
confusing, static tokens outnumbering actual functional ones:
{% include "name_snippet.html" with name as "Joe" and greeting as
"Hello" %}

My proposal is that the current {% with name as "Joe" %} format
becomes the legacy format, and that the new format becomes (also
allowing for multiple arguments):
{% with name="Joe" greeting="Hello" %}

Other tags which currently use the "as" token are: cycle, regroup and
url. These all introduce a new variable into the current context,
which does differ slightly from how {% with %} alters a variable in a
contained scope. So my secondary (perhaps somewhat feeble) argument is
that this actually helps to keep the "as" token's behaviour more
consistent. :)

Thoughts?

[David Danier]

> Other tags which currently use the "as" token are: cycle, regroup and
> url. These all introduce a new variable into the current context,
> which does differ slightly from how {% with %} alters a variable in a
> contained scope. So my secondary (perhaps somewhat feeble) argument is
> that this actually helps to keep the "as" token's behaviour more
> consistent. :)

Don't forget {% blocktrans %}. Using the foo=bar-syntax here may be
slightly more difficult due to counted arguments.

{% blocktrans count foo as var1 and bar as var2 %}
Could become:
{% blocktrans count var1=foo var2=bar %}

David

[Russell Keith-Magee]

Repeating what I said to Chris in IRC for the benefit of posterity:

I don't have any strong preference either way, but whatever style we
pick, we need to be consistent.

I can certainly appreciate the clarity and terseness of the "foo=bar
pork=ham" syntax. My only concern would be whether it is too
"programmery" for the intended audience of the template language. We
have existing uses of the 'x=y' syntax -- such as in the {% url %}
tag, so I don't think this should be a major concern.

As David points out, the fact that {% blocktrans %} already does 'with
X as Y and A as B' would seem to set a precedent for the verbose
syntax. This verbose syntax is also syntactically consistent with what
the {% with %} tag already does, so there's no need to introduce a
'legacy' format.

I could swing either way on this. If we were starting with a clean
slate, I'd prefer the terse syntax, and I think Chris provides a
reasonable argument for how the usage of 'as' can be explained
conceptually. However, the legacy issue and the precendent set by {%
blocktrans %} provides a compelling argument to use the more verbose
syntax.

If we can introduce the terse syntax while maintaining the old syntax
(including the analogous change in blocktrans), I think it would be a
worthwhile change. However, I certainly won't complain if public
opinion sways the other way.

Yours,
Russ Magee %-)

[Harro]

I would suggest also adding a way to exclude all context except items
specified with the with syntax.
(nocontext keyword or something like that).

Because sometimes I have certainly named items in my context which can
also be used in the included template but I don't want there. Sure you
can overwrite them one by one, but the faster and cleaner way would be
to exclude the whole context.


On Oct 29, 3:22 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

[SmileyChris]

On Oct 29, 2:22 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

> If we can introduce the terse syntax while maintaining the old syntax
> (including the analogous change in  blocktrans), I think it would be a
> worthwhile change. However, I certainly won't complain if public
> opinion sways the other way.

I've done this here:
http://github.com/SmileyChris/django/compare/master...7817-include-with

[Jannis Leidel]

On 27.10.2010, at 09:46, SmileyChris wrote:

> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>> I would like to bring this up again, because this is something that
>> would really improve readability of my templates. I'm mainly
>> interested in ticket #7817 (the include tag changes), but extending
>> "with" tag (ticket 9456) would keep things consistent.
>
> Here's a link to the ticket for the lazier ones among us:
> http://code.djangoproject.com/ticket/7817
>
> The main decision which needs to be made is one of syntax.
>
> The current proposal uses:
> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
> but this introduces an inconsistency with the {% with %} tag.

I'm feeling strongly against moving from the "value as name" to the "name=value" notation, since I think the former is actually more readable than the latter for the targetted audience (template authors).

> Consistency would be nice, but I think this starts to look a bit
> confusing, static tokens outnumbering actual functional ones:
> {% include "name_snippet.html" with name as "Joe" and greeting as
> "Hello" %}

Well, I think that's actually not a bad notation at all (if using the correct order :), so for #7817 I propose the following syntax (as analogously proposed by #9456 for {% with %}):

{% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}

Jannis

[bur...@gmail.com]

Hi Jannis,

On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel <jan...@leidel.info> wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the "name=value" notation, since I think the former is actually more readable than the latter for the targetted audience (template authors).

If you are not asking real people, it's a speculation anyway.

I'm also target audience (since I write initial Django templates
structure for HTML from designer), even though I'm a programmer.
I think there are even more programmers than designers that use django
templates.
Our designer don't care at all, because she will just use any solution
to do her job.
So of two people, one voted for "=", second abstained from voting.

I think for most people "=" is slightly better than "as" because:
- All of them had math classes at school and they know "=" already.
- Not every Django template author knows English.

"Slightly" because:
- they have to spend some minutes to understand "how the tag works"
anyway, and it's much more time than they would think of "what does
'=' do here" or "what does 'as' means here".
- they just don't care. they didn't choose html, they didn't choose
css, they didn't choose django templates. it's so minor question.

Why I'm for "=":

I think, "and" + "as" are too verbose for this regular task.
They just make fast scanning through the template seeking for some
variables much harder and don't help at all.

>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct order :), so for #7817 I propose the following syntax (as analogously proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
>
> Jannis
>

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

[Jannis Leidel]

On 03.11.2010, at 12:01, bur...@gmail.com wrote:

> Hi Jannis,
>
> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel <jan...@leidel.info> wrote:
>> On 27.10.2010, at 09:46, SmileyChris wrote:
>>
>>> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>>>> I would like to bring this up again, because this is something that
>>>> would really improve readability of my templates. I'm mainly
>>>> interested in ticket #7817 (the include tag changes), but extending
>>>> "with" tag (ticket 9456) would keep things consistent.
>>>
>>> Here's a link to the ticket for the lazier ones among us:
>>> http://code.djangoproject.com/ticket/7817
>>>
>>> The main decision which needs to be made is one of syntax.
>>>
>>> The current proposal uses:
>>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>>> but this introduces an inconsistency with the {% with %} tag.
>>
>> I'm feeling strongly against moving from the "value as name" to the "name=value" notation, since I think the former is actually more readable than the latter for the targetted audience (template authors).
>
> If you are not asking real people, it's a speculation anyway.

Heh, so you are saying my gut feeling is speculative, I'm not sure what to respond to that. In any case, you are implying that I'm not "real people" -- what ever that is -- I can assure you that I use templates as a programmer and a designer. In case you think "we programmers can do whatever we want, the designer won't even notice the api change", I have to admit the designer in me feels a little insulted.

It does make a difference to use a mathamatical sign in a commonly used aspect of the template language than prose. Note, I'm not saying that I disagree with getting rid of warts (#7817, #9456), but actually proposed a compromise that was already mentioned by another core dev.

[bur...@gmail.com]

On Wed, Nov 3, 2010 at 5:18 PM, Jannis Leidel <jan...@leidel.info> wrote:
> On 03.11.2010, at 12:01, bur...@gmail.com wrote:
>
>> Hi Jannis,
>>
>> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel <jan...@leidel.info> wrote:
>>> On 27.10.2010, at 09:46, SmileyChris wrote:
>>>
>>>> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>>>>> I would like to bring this up again, because this is something that
>>>>> would really improve readability of my templates. I'm mainly
>>>>> interested in ticket #7817 (the include tag changes), but extending
>>>>> "with" tag (ticket 9456) would keep things consistent.
>>>>
>>>> Here's a link to the ticket for the lazier ones among us:
>>>> http://code.djangoproject.com/ticket/7817
>>>>
>>>> The main decision which needs to be made is one of syntax.
>>>>
>>>> The current proposal uses:
>>>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>>>> but this introduces an inconsistency with the {% with %} tag.
>>>
>>> I'm feeling strongly against moving from the "value as name" to the "name=value" notation, since I think the former is actually more readable than the latter for the targetted audience (template authors).
>>
>> If you are not asking real people, it's a speculation anyway.
>
> Heh, so you are saying my gut feeling is speculative, I'm not sure what to respond to that. In any case, you are implying that I'm not "real people" -- what ever that is -- I can assure you that I use templates as a programmer and a designer. In case you think "we programmers can do whatever we want, the designer won't even notice the api change", I have to admit the designer in me feels a little insulted.
>
> It does make a difference to use a mathamatical sign in a commonly used aspect of the template language than prose.  Note, I'm not saying that I disagree with getting rid of warts (#7817, #9456), but actually proposed a compromise that was already mentioned by another core dev.

I also don't disagree, just not completely agree with your reasoning.

Sorry for being harsh. Just "my inner designer" gets confused when
someone calls "as" and "and" much useful for purpose of setting
variables rather than "=". Hm.... Maybe because HTML uses "=" for
setting attributes? :)

>>>> Consistency would be nice, but I think this starts to look a bit
>>>> confusing, static tokens outnumbering actual functional ones:
>>>> {% include "name_snippet.html" with name as "Joe" and greeting as
>>>> "Hello" %}
>>>
>>> Well, I think that's actually not a bad notation at all (if using the correct order :), so for #7817 I propose the following syntax (as analogously proposed by #9456 for {% with %}):
>>>
>>> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>

[Łukasz Rekucki]

My argument against this is that it's not consistent use of "as". Take
the {% url %} tag:

{% url my_view object_id=5 section="B" as my_view_url %}

There is clear separation about what is an argument to the tag and
what is being set in current scope. Now {% with %} and {% blocktrans
%} behave the same with a small difference of changing current scope.

{% with "John" as person_name %}
{# context was changed by using "as" and person_name is now availble #}
{% endwith %}

Thus I would leave {% with %} and {% blocktrans %} with this syntax as
it's intuitive and readable. The proposed change to {% include %} is a
bit diffrent. Currently, there is a way to write inclusion tags and
pass arguments to them, that usually land in the context. So my custom
inclusion tag right now will look like this:

{% show_note note "Title" %}

If we were to extend the inclusion tag shortcut to support keyword
arguments I think most people would expect it to look like this:

{% show_note note=object title="Title" %}

rather than:

{% show_note object as note and "Title" as title %}

because that's how most tags get their arguments passed. {% include %}
with proposed extensions can be considered as a inclusion_tag with a
variable template name:

{% include "foo.html" x=1 y=2 %}

It takes arguments and doesn't modify scope, so It should be
consistent with tags that do the same. The interleaving "with" keyword
could be removed not to confuse people.

--
Łukasz Rekucki

[silent1mezzo]

+1 for {% include "foo.html" x=1 y=2 %}

This just seems more natural. My designer agreed based on the {% url
%} tags.

[Peter Baumgartner]

+1 for using the = syntax here. My reasons have been mentioned above,
but to recap:

* and/as gets too verbose and difficult to read if you add more than a
couple variables
* HTML uses "=" to set attributes, so this shouldn't be a new paradigm
for template authors

-- Pete

[Gabriel Hurley]

In a fit of coincidental timing, I was just being frustrated by this
very issue with inclusion tags today. I'm +1 on supporting kwargs with
"=". It is in fact *more* familiar to someone who works with HTML to
be able to assign attributes in arbitrary order, for example:

<a href="http://example.com" class="green" id="my_id">

works the same as:

<a id="my_id" class="green" href="http://example.com">

whereas this is just nonsense:

<a "http://example.com" "my_id" "green">

and this is even more broken:

<a http://example.com as src and my_id as id and green as class>

So any argument about not using kwargs being "for template authors"
seems a bit silly to me. Designers may not be programmers (though many
of them are these days), but the reality of the tools they already use
is that this is a familiar syntax.

All the best,

- Gabriel

On Nov 8, 7:16 pm, Peter Baumgartner <sgt.hu...@gmail.com> wrote:

[Jannis Leidel]

On 10.11.2010, at 09:20, Gabriel Hurley wrote:

> In a fit of coincidental timing, I was just being frustrated by this
> very issue with inclusion tags today. I'm +1 on supporting kwargs with
> "=". It is in fact *more* familiar to someone who works with HTML to
> be able to assign attributes in arbitrary order, for example:
>
> <a href="http://example.com" class="green" id="my_id">
>
> works the same as:
>
> <a id="my_id" class="green" href="http://example.com">
>
> whereas this is just nonsense:
>
> <a "http://example.com" "my_id" "green">
>
> and this is even more broken:
>
> <a http://example.com as src and my_id as id and green as class>

While I appreciate that you think that's a fact, comparing HTML semantics with those of the template language doesn't proof anything, at the most shows that they both have the concept of parameters. If that's all you are implying we should probably move to using arrow brackets?

> So any argument about not using kwargs being "for template authors"
> seems a bit silly to me. Designers may not be programmers (though many
> of them are these days), but the reality of the tools they already use
> is that this is a familiar syntax.

Please stop trying to make a point by calling my argument silly. I've voiced my strong concerns about the proposed change but agreed with a different proposal.

Jannis

[Luke Plant]

Nice work. I also find the '=' format more readable, and definitely
appropriate for the reasons given by others. With the others fixed to be
consistent Russell's concerns are addressed. It seems only Jannis is
opposed to this syntax so far, and several core developers as well as
everyone else on the thread prefer it. Are we close enough to "rough
consensus" yet?

Luke

--
I never hated a man enough to give him his diamonds back. (Zsa Zsa
Gabor)

Luke Plant || http://lukeplant.me.uk/

[Jannis Leidel]

On 10.11.2010, at 11:09, Luke Plant wrote:

> On Sun, 2010-10-31 at 16:59 -0700, SmileyChris wrote:
>> On Oct 29, 2:22 pm, Russell Keith-Magee <russ...@keith-magee.com>
>> wrote:
>>> If we can introduce the terse syntax while maintaining the old syntax
>>> (including the analogous change in blocktrans), I think it would be a
>>> worthwhile change. However, I certainly won't complain if public
>>> opinion sways the other way.
>>
>> I've done this here:
>> http://github.com/SmileyChris/django/compare/master...7817-include-with
>
> Nice work. I also find the '=' format more readable, and definitely
> appropriate for the reasons given by others. With the others fixed to be
> consistent Russell's concerns are addressed. It seems only Jannis is
> opposed to this syntax so far, and several core developers as well as
> everyone else on the thread prefer it. Are we close enough to "rough
> consensus" yet?

Not really, I'm -1 on this and gave a different proposal that doesn't get rid of an existing paradigm and would solve the issues for me (+0).

BTW, while looking trough Chris' patch again I noticed another wart of his proposed change regarding filters when used in the parameter assignment.

{% blocktrans with berta=anton|lower %}{{ berta }}{% endblocktrans %}

The version that works today:

{% blocktrans with anton|lower as berta %}{{ berta }}{% endblocktrans %}

The include proposed by Chris:

{% include "basic-syntax03" with first=second|lower|upper second=first|upper %}

and the more verbose version that corresponds to how the template language works today:

{% include "basic-syntax03" with first|lower|upper as new_first and second|upper as new_second %}

Jannis

[Gabriel Hurley]

I apologize for the unintentional insult. In retrospect "silly" was a
poor choice of words, and certainly not directed at you specifically,
Jannis. Your opinion is plenty valid, even if we disagree.

The real crux of my argument is this: Django's philosophy of keeping
programming concerns out of templates is a great principle; however,
it creeps into a tacit implication that template authors (in other
words, designers) need to be treated with kid gloves. As someone who
actually came up *as a designer* before I ever learned to code, and
who has been very involved in design communities in the past, I find
the implied necessity of readability specifically for "the target
audience" (designers) mildly pejorative. I'm sure it's not always
meant that way, but that's how it feels when I read these types of
rationales. I'm +1 on readability for readability's sake. -1 on
readability for the sake of "the target audience".

Getting back to the real subject at hand, I like the general human
readability of your syntax (and the current syntax in general), I just
like the "=" a little more. I'm +1 on "=", and +0 on "... as ...".
Either one gets the job done and I'd gladly accept either as they both
solve the same problems.

Thanks!

- Gabriel

On Nov 10, 1:36 am, Jannis Leidel <jan...@leidel.info> wrote:
> On 10.11.2010, at 09:20, Gabriel Hurley wrote:
>
>
>
>
>
>
>
>
>
> > In a fit of coincidental timing, I was just being frustrated by this
> > very issue with inclusion tags today. I'm +1 on supporting kwargs with
> > "=". It is in fact *more* familiar to someone who works with HTML to
> > be able to assign attributes in arbitrary order, for example:
>
> > <a href="http://example.com" class="green" id="my_id">
>
> > works the same as:
>
> > <a  id="my_id" class="green" href="http://example.com">
>
> > whereas this is just nonsense:
>
> > <a "http://example.com" "my_id" "green">
>
> > and this is even more broken:
>

> > <ahttp://example.comas src and my_id as id and green as class>

[Luke Plant]

On Wed, 2010-11-10 at 11:34 +0100, Jannis Leidel wrote:

> Not really, I'm -1 on this and gave a different proposal that doesn't
> get rid of an existing paradigm and would solve the issues for me
> (+0).

OK, there was no further progress after that, and it would be nice to
find some way to move along. It's not really fair to say that the
proposal gets rid of an existing paradigm as if that's a negative thing.
If you consider this as a case of defining key/value pairs, the url tag
already does it the proposed way, so we have two paradigms, and it is
better to choose one going forward (as we did with things like whether
backend settings should specify the module or the class).

For the people who have worked on this, I think it would be shame for
this feature to get stuck at this point. Our contributing guidelines
say:

Since this process allows any core committer to veto a proposal, any
"-1" votes (or BDFL vetos) should be accompanied by an explanation that
explains what it would take to convert that "-1" into at least a "+0".

From what I can tell, it appears that the answer would be "use the 'as'
syntax instead of the '=' syntax". To me, it doesn't seem fair to use a
-1 vote in this way, since the choice of syntax is definitely a
subjective matter and:

1) there is precedent for the proposed syntax in the Django template
system.

2) all the other people who have weighed in, including 3 core devs,
actually prefer the proposed syntax.

> BTW, while looking trough Chris' patch again I noticed another wart of
his proposed change regarding filters when used in the parameter
assignment.
>
> {% blocktrans with berta=anton|lower %}{{ berta }}{% endblocktrans
%}
>
> The version that works today:
>
> {% blocktrans with anton|lower as berta %}{{ berta }}{%
endblocktrans %}
>
> The include proposed by Chris:
>
> {% include "basic-syntax03" with first=second|lower|upper
second=first|upper %}
>
> and the more verbose version that corresponds to how the template
language works today:
>
> {% include "basic-syntax03" with first|lower|upper as new_first and
second|upper as new_second %}
>

I'm afraid I didn't understand your comments here.

Regards,

Luke

--
I teleported home one night
With Ron and Sid and Meg,
Ron stole Meggie's heart away
And I got Sidney's leg
(THHGTTG)

Luke Plant || http://lukeplant.me.uk/

[Russell Keith-Magee]

On Thu, Nov 18, 2010 at 11:04 PM, Luke Plant <L.Pla...@cantab.net> wrote:
> On Wed, 2010-11-10 at 11:34 +0100, Jannis Leidel wrote:
>
>> Not really, I'm -1 on this and gave a different proposal that doesn't
>> get rid of an existing paradigm and would solve the issues for me
>> (+0).
>
> OK, there was no further progress after that, and it would be nice to
> find some way to move along.

Completely agreed. Syntax notwithstanding, the feature is a good idea.

> It's not really fair to say that the
> proposal gets rid of an existing paradigm as if that's a negative thing.
> If you consider this as a case of defining key/value pairs, the url tag
> already does it the proposed way, so we have two paradigms, and it is
> better to choose one going forward (as we did with things like whether
> backend settings should specify the module or the class).
>
> For the people who have worked on this, I think it would be shame for
> this feature to get stuck at this point. Our contributing guidelines
> say:
>
>  Since this process allows any core committer to veto a proposal, any
>  "-1" votes (or BDFL vetos) should be accompanied by an explanation that
>  explains what it would take to convert that "-1" into at least a "+0".
>
> From what I can tell, it appears that the answer would be "use the 'as'
> syntax instead of the '=' syntax". To me, it doesn't seem fair to use a
> -1 vote in this way, since the choice of syntax is definitely a
> subjective matter and:
>
> 1) there is precedent for the proposed syntax in the Django template
>   system.
>
> 2) all the other people who have weighed in, including 3 core devs,
>   actually prefer the proposed syntax.

I should point out that my support is a +0, not +1. If we were
starting with a clean slate, I prefer the terse syntax, but blocktrans
sets a compelling precedent to go the other way.

However, given the Unless Jannis is willing to downgrade his -1 to a
-0, I think a BDFL judgement is called for here.

I believe Jacob is travelling at the moment; so if anyone sees him,
poke him and point him in the general direction of this thread.

To summarize, the options on the table are:

OPTION 1:

{% include "foo.html" with a as foo and b as bar %}
{% with a as foo and b as bar %}

Pros:
* Consistent with existing 1-clause {% with %} tag, and the syntax of
{% blocktrans %}
* Establishes an overall design where "as" is used to set variables
(both in current context and internal to blocks).

Cons:
* Verbose. Lots of placeholder keywords required.

OPTION 2:

{% include "foo.html" with a=foo b=bar %}
{% with a=foo b=bar %}

Pros:
* Terse
* Consistent with syntax for the {% url %} tag
* Allows us to establish an overall design where the "as" keyword is
used to set something in the current context; tags that set variables
that only apply in that template block use assignment (However, this
doesn't work retrospectively for {% with a as foo %} or {% blocktrans
%}).

Cons:
* Inconsistent with existing {% with %} implementation; would
require a compatibility option for the single variable case of with,
and for blocktrans.
* Could be considered to be too "programmery".

Yours,
Russ Magee %-)

[Jannis Leidel]

On 18.11.2010, at 16:04, Luke Plant wrote:

> On Wed, 2010-11-10 at 11:34 +0100, Jannis Leidel wrote:
>
>> Not really, I'm -1 on this and gave a different proposal that doesn't
>> get rid of an existing paradigm and would solve the issues for me
>> (+0).
>
> OK, there was no further progress after that, and it would be nice to
> find some way to move along. It's not really fair to say that the
> proposal gets rid of an existing paradigm as if that's a negative thing.

Well, it's a negative thing (to me) if the paradigm that is proposed to be replaced is actual a good idea to me. If that seems not fair to you, I want to assure you that this isn't my intent. On the contrary, I gave specific reasons why I think it's not a good idea to me and proposed a different way of handling it (which isn't completely out of the world but was mentioned in the first mail from Chris).

> If you consider this as a case of defining key/value pairs, the url tag
> already does it the proposed way, so we have two paradigms, and it is
> better to choose one going forward (as we did with things like whether
> backend settings should specify the module or the class).

The url tag has different reasons to use that kind of notation, as it basically implements the *args and *kwargs protocol for positional and keyword arguments, e.g.:

{% url my-view 123 %}
{% url my-other-view user_id=123 %}

The proposed syntax for the {% with %} and {% include %} tag on the other hand doesn't relate to this concept, unless you think the context enclosed by {% with %} and the template included by {% include %} match the concept of a callable.

> For the people who have worked on this, I think it would be shame for
> this feature to get stuck at this point. Our contributing guidelines
> say:
>
> Since this process allows any core committer to veto a proposal, any
> "-1" votes (or BDFL vetos) should be accompanied by an explanation that
> explains what it would take to convert that "-1" into at least a "+0".
>
> From what I can tell, it appears that the answer would be "use the 'as'
> syntax instead of the '=' syntax". To me, it doesn't seem fair to use a
> -1 vote in this way, since the choice of syntax is definitely a
> subjective matter and:
>
> 1) there is precedent for the proposed syntax in the Django template
> system.

Again, I think the actual precedence here is the {% blocktrans %} tag, which already implements the concept of passing a specific value to the enclosed content.

> 2) all the other people who have weighed in, including 3 core devs,
> actually prefer the proposed syntax.

Okay, and I don't prefer the proposed syntax.

>> BTW, while looking trough Chris' patch again I noticed another wart of
> his proposed change regarding filters when used in the parameter
> assignment.
>>
>> {% blocktrans with berta=anton|lower %}{{ berta }}{% endblocktrans
> %}
>>
>> The version that works today:
>>
>> {% blocktrans with anton|lower as berta %}{{ berta }}{%
> endblocktrans %}
>>
>> The include proposed by Chris:
>>
>> {% include "basic-syntax03" with first=second|lower|upper
> second=first|upper %}
>>
>> and the more verbose version that corresponds to how the template
> language works today:
>>
>> {% include "basic-syntax03" with first|lower|upper as new_first and
> second|upper as new_second %}
>>
> I'm afraid I didn't understand your comments here.

My comments refered to using template filters with the newly proposed syntax and how it's less readible than using template filters with the "'as' syntax" to me.

Jannis

[Jacob Kaplan-Moss]

On Thu, Nov 18, 2010 at 9:47 AM, Russell Keith-Magee
<rus...@keith-magee.com> wrote:
> However, given the Unless Jannis is willing to downgrade his -1 to a
> -0, I think a BDFL judgement is called for here.

Let's go with {% with a=foo b=bar %}.

Jacob

[Michael Sprayberry]

--- On Tue, 11/30/10, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:

-- I have to agree lets go with {% with a=foo b=bar %}   Michael

[Łukasz Rekucki]

Does this mean I can also switch #9456 to Accepted (and update the syntax) ? ;)

[1]: http://code.djangoproject.com/ticket/9456

--
Łukasz Rekucki

[Russell Keith-Magee]

2010/12/3 Łukasz Rekucki <lrek...@gmail.com>:

I've just updated the two tickets.

Yours,
Russ Magee %-)