Re: Revisiting multiline tags

[Collin Anderson]

Here's the actual code PR https://github.com/django/django/pull/2556

On Sun, Mar 13, 2016 at 1:26 AM, Martijn van Oosterhout 
wrote:

>
> On 12 March 2016 at 05:31, Curtis Maloney  wrote:
>
> I think this conversation needs to come to a conclusion, and that
>>> conclusion should be simple. Several people have asked a very simple
>>> question of the purists: what is the "correct" way of writing tags which
>>> by nature need to be very long, without line breaks and without them
>>> being 400 characters long. If no acceptable answer can be given, we need
>>> to just implement the line break mechanic and give the developers back
>>> their whitespace.
>>>
>>
>> As pointed out by Josh in another email, I wrote a patch to permit
>> multi-line tags.  I asked for feedback.  I got _none_.
>>
>> If people really wanted this feature, why didn't we hear more about it?
>> What can we do to get more people to know about it, and to give more
>> feedback?
>>
>> I would recommend you review the history of this discussion, collect the
>> pros and cons, formulate a DEP, and we can go from there.
>>
>> I'm quite sure the patch will still work fine.
>>
>>
> Presumably you're talking about this:
> https://github.com/django/deps/pull/3/files
>
> I'm not sure what feedback you're expecting, but if +1's are what's
> needed, then here you go: +1.
>
> The thing is, this feature is a nice to have but no show stopper. The
> first time a developer runs into this (by trying the obvious and finding it
> doesn't work), they'll check the documentation, shrug their shoulders at
> the weird Django developers and get on with their job.
>
> Perhaps 1% will go to the effort of seeing if it has been proposed, find
> it's been mentioned several times and think "someone is working on it" and
> get on with their job.
>
> Perhaps 1% of those will note it hasn't been done yet, dig deeper and find
> your proposal and the various bugs, note it's been blocked, figure it's a
> lost cause and get on with their job.
>
> If this change requires a horde of developers waking up and calling for
> it, then it's never going to happen. The current situation will however
> continue to cause wasted developer time until eternity. Simply because
> there is no obvious reason why it shouldn't work. It's not ambiguous, it's
> not going to confuse anyone, it's just one of those little things that
> makes computers just a little bit more user friendly.
>
> Have a nice day,
> --
> Martijn van Oosterhout  http://svana.org/kleptog/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADWG95v7eMb8u85PyS3MsigXMVoKs3a_H9zx8aGJBsetBaWyLQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S6iJt9DCuRM5LKDWX%3DB02BUq7zBgf8TDp3-%2BrC4xGHLRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Martijn van Oosterhout]

On 12 March 2016 at 05:31, Curtis Maloney  wrote:

I think this conversation needs to come to a conclusion, and that
>> conclusion should be simple. Several people have asked a very simple
>> question of the purists: what is the "correct" way of writing tags which
>> by nature need to be very long, without line breaks and without them
>> being 400 characters long. If no acceptable answer can be given, we need
>> to just implement the line break mechanic and give the developers back
>> their whitespace.
>>
>
> As pointed out by Josh in another email, I wrote a patch to permit
> multi-line tags.  I asked for feedback.  I got _none_.
>
> If people really wanted this feature, why didn't we hear more about it?
> What can we do to get more people to know about it, and to give more
> feedback?
>
> I would recommend you review the history of this discussion, collect the
> pros and cons, formulate a DEP, and we can go from there.
>
> I'm quite sure the patch will still work fine.
>
>
Presumably you're talking about this:
https://github.com/django/deps/pull/3/files

I'm not sure what feedback you're expecting, but if +1's are what's needed,
then here you go: +1.

The thing is, this feature is a nice to have but no show stopper. The first
time a developer runs into this (by trying the obvious and finding it
doesn't work), they'll check the documentation, shrug their shoulders at
the weird Django developers and get on with their job.

Perhaps 1% will go to the effort of seeing if it has been proposed, find
it's been mentioned several times and think "someone is working on it" and
get on with their job.

Perhaps 1% of those will note it hasn't been done yet, dig deeper and find
your proposal and the various bugs, note it's been blocked, figure it's a
lost cause and get on with their job.

If this change requires a horde of developers waking up and calling for it,
then it's never going to happen. The current situation will however
continue to cause wasted developer time until eternity. Simply because
there is no obvious reason why it shouldn't work. It's not ambiguous, it's
not going to confuse anyone, it's just one of those little things that
makes computers just a little bit more user friendly.

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADWG95v7eMb8u85PyS3MsigXMVoKs3a_H9zx8aGJBsetBaWyLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

On 12/03/16 11:47, Nathan Cox wrote:

I don't understand why this conversation has had to go on for this long.



The original post was in February of 2012, and it is now March of 2016.
That's four years of discussion that basically boils down to a couple of
purists insisting that their coding style is the only coding style, fits
every possible scenario and is beautiful, while a much larger group
comes up with scenarios where the given style guide is counterintuitive
and difficult to read.


I think, really, the core issue is a philosophical one, and it comes 
down to this:


Will making this change encourage people to put more work in templates?

Or, more, will it stop discouraging people from providing clean, simple 
interfaces in the context, instead of requiring template authors to do 
more work?


Personally, I think it's a tiny issue drastically outweighed by the 
advantages -- especially for the translation cases raised.



I think the salient fact here is that templating languages are supposed
to be supersets of HTML, and as supersets should respect the native
abilities of their parents.


I disagree here.  Whilst the most common use is for rendering HTML, it 
is frequently used for other cases.


Also, DTL quite specifically is NOT html-like to make it more widely usable.


With HTML it is common and accepted to break
tags with many attributes across multiple lines so that the code itself
is easy to read (i.e., "visually parse", a term used frequently in this
thread). This same convention extends into the Python world, where long
lines can easily be broken down using parenthesis to maintain language
constraints while allowing for ease of readability. In fact, PEP8
specifically prohibits lines longer than 80 characters, and even people
who break that generally respect something along the lines of 99. Two
Scoops will tell you that any community software should be a hard limit
of 80, while internal projects can be allowed to go to 99 with group
consensus.


From memory, Django itself uses a 119 char line limit - in deference to 
the prevalence of widescreen monitors.


Even so, I do agree long lines reduce readability.


So you have a python templating language for generating HTML, two
languages which both embrace multi-line statements merging together, but
we can't agree that it should probably also support this?


Well, we have a templating language... implemented in Python - but quite 
specifically _not_ python itself... primarily for rendering HTML, but 
specifically engineered to not be limited to it...


So you can see how some might think this argument is weak...


I think this conversation needs to come to a conclusion, and that
conclusion should be simple. Several people have asked a very simple
question of the purists: what is the "correct" way of writing tags which
by nature need to be very long, without line breaks and without them
being 400 characters long. If no acceptable answer can be given, we need
to just implement the line break mechanic and give the developers back
their whitespace.


As pointed out by Josh in another email, I wrote a patch to permit 
multi-line tags.  I asked for feedback.  I got _none_.


If people really wanted this feature, why didn't we hear more about it? 
 What can we do to get more people to know about it, and to give more 
feedback?


I would recommend you review the history of this discussion, collect the 
pros and cons, formulate a DEP, and we can go from there.


I'm quite sure the patch will still work fine.

--
C

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56E39BA0.2070007%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Josh Smeaton]

Funkybob (Curtis Maloney) implemented a multiline template tag patch nearly 
two years ago. He asked for feedback a number of times and received none. I 
think there's enough support here that if someone were to implement a 
patch, it'd probably be accepted. Adding the same argument as to why 
multiline tags would be useful isn't helpful anymore. The arguments have 
been made.

Adrian requested the pros/cons be written up as a DEP. Curtis began one but 
it seems to have disappeared, I assume because there was lack of review or 
interest. If you feel strongly enough for this change please feel free to 
write up a DEP or even a patch that implements multiline tags, paying 
particular attention to ensure performance isn't hindered (as discussed 
above).

Core devs have only so much time to work on features. If a feature isn't 
more important to them than something else, chances are it won't get 
implemented by them. Everyone is free to (and encouraged to!) implement 
features themselves. A core dev will review it. Non core developers are 
also free to (and encouraged to) review it.

I know it sounds like I'm putting forth the "PRs accepted" brush off line, 
but there's elements of truth in that statement. Curtis wrote a patch and 
no one tested it. How important is this feature again?


On Saturday, 12 March 2016 11:54:46 UTC+11, Nathan Cox wrote:
>
> I don't understand why this conversation has had to go on for this long.
>
> The original post was in February of 2012, and it is now March of 2016. 
> That's four years of discussion that basically boils down to a couple of 
> purists insisting that their coding style is the only coding style, fits 
> every possible scenario and is beautiful, while a much larger group comes 
> up with scenarios where the given style guide is counterintuitive and 
> difficult to read.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e40ff1fe-3cca-468a-9837-c5b7b53c0c5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Nathan Cox]

I don't understand why this conversation has had to go on for this long.

The original post was in February of 2012, and it is now March of 2016. 
That's four years of discussion that basically boils down to a couple of 
purists insisting that their coding style is the only coding style, fits 
every possible scenario and is beautiful, while a much larger group comes 
up with scenarios where the given style guide is counterintuitive and 
difficult to read.

I think the salient fact here is that templating languages are supposed to 
be supersets of HTML, and as supersets should respect the native abilities 
of their parents. With HTML it is common and accepted to break tags with 
many attributes across multiple lines so that the code itself is easy to 
read (i.e., "visually parse", a term used frequently in this thread). This 
same convention extends into the Python world, where long lines can easily 
be broken down using parenthesis to maintain language constraints while 
allowing for ease of readability. In fact, PEP8 specifically prohibits 
lines longer than 80 characters, and even people who break that generally 
respect something along the lines of 99. Two Scoops will tell you that any 
community software should be a hard limit of 80, while internal projects 
can be allowed to go to 99 with group consensus. 

So you have a python templating language for generating HTML, two languages 
which both embrace multi-line statements merging together, but we can't 
agree that it should probably also support this?

I think this conversation needs to come to a conclusion, and that 
conclusion should be simple. Several people have asked a very simple 
question of the purists: what is the "correct" way of writing tags which by 
nature need to be very long, without line breaks and without them being 400 
characters long. If no acceptable answer can be given, we need to just 
implement the line break mechanic and give the developers back their 
whitespace.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/06029153-7606-4047-b6a4-7d0d1b9dd04d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Flimm]

+1 from me. blocktrans is really ugly if it has to fit in one line.

On Saturday, February 18, 2012 at 7:04:33 AM UTC+1, Glenn Washburn wrote:
>
> Hello django devers,
>
> I'd like to reopen discussion on the multiline tag issue (see:
> https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.
>
> I've done rudimentary testing on a 6 character change in 1.3.1 to
> template.base.tags_re (add the re.S flag to the regex), which appears
> to solve the issue.  So I don't see all the work which was being
> referred to in mtredinnick's point two.  Perhaps the template engine
> has been rewritten since then.  The only test that fails after making
> this change (in 1.3.1) is the one that explicitly tests that tgs should
> not be multiline.
>
> Since this change appears to be so low impact and such a simple
> change.  Are there any reasons why this change shouldn't be included in
> django?  Maybe I'm missing something.
>
> Its interesting to note that
> https://code.djangoproject.com/ticket/3888, which is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.
>
> -Glenn
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/06f69eec-5eac-4a1d-bed3-bf3bbd25a62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Martijn van Oosterhout]

I'm working on a project trying to internationalise all the templates and 
ran into this problem today, with the blocktrans tag as mentioned earlier. 
Since the DEP doesn't appear to be going anywhere, I'd like to suggest some 
alternatives which might be more palatable.

Since the problem appears to be with the blocktrans tag, perhaps we should 
fix it there? The only reason that you need these long lines is because the 
blocktrans tag doesn't allow real variables. But that sounds like a 
restriction that could be lifted. So instead of:

  {% blocktrans with foo=a.b.c bar=b.c.d %}{{ foo }} {{ bar }}{% 
endblocktrans %}

You could simply say:

  {% blocktrans %}{{ a.b.c }} {{ b.c.d }}{% endblocktrans %}

In the output PO file these could just be assigned hidden variables like _1 
or something (you could try to be smarter I guess).

I'd actually like the variable interpolation to be expanded to handle cases 
like:

  {% blocktrans %}For more help click {{ '' }}here{{ '' 
}}{% endblocktrans %}

using the same hidden variables as above. That would make it much easier to 
separate the text from the layout. Perhaps even {{ '' as 
beginlink }} to specify the variable name.

A lame suggestion is to require backslashes for line continuation within 
tags. For the syntax it;s not strictly required, but it might help with the 
backward compatibility concerns.

While I'm giving suggestions, I'd also like to add something to help with 
getting everything on one line. So something like:

  {% blocktrans spaceless %}
  A rather
  long line
  {% endblocktrans %}

This would strip any spaces so everything appears on one line in the PO 
file.

Thoughts?

On Saturday, May 10, 2014 7:01:15 PM UTC+2, ted wrote:
>
> Let me rephrase -- Where do I voice support that I too would like this 
> feature? Here, on the DEP pull request, on the original ticket?
>
> I get that there is a difference between core devs voting and non core 
> devs voicing support, and that +1 from a core dev is a vote whereas +1 from 
> a non-core user is an expression of support.  That wasn't the question. 
>  The question is about how to most effectively join the chorus so core devs 
> know that people do care about this when they cast their votes.
>
> T
>
> On Tuesday, April 29, 2014 10:24:12 PM UTC-4, Florian Apolloner wrote:
>>
>> Technically I'd think only core devs would vote. So neither here or there 
>> would make a diff imo.
>>
>> P.S.: That said I am not sure we have a formal policy on how we act on 
>> DEPs yet (or maybe I should just read DEP 001 more carefully ;))
>>
>> Cheers,
>> Florian
>>
>> On Wednesday, April 30, 2014 4:02:26 AM UTC+2, ted wrote:
>>>
>>> Now that there is a DEP, where do we voice our support (cast +1 votes)? 
>>>  Here, on the DEP pull request, on the original ticket?
>>>
>>> T
>>>
>>> On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote:

 On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>
> And for the last month or so a patch has existed and feedback has been 
> requested. Performance was one of the concerns mentioned, so download 
> Curtis' patch, and test that it works for your use case. He has asked for 
> feedback a number of times. Unless you try it out, I fear that you won't 
> be 
> seeing multi-line tags.
>

 My thought exactly.

 I intend to review the patch, benchmark it, and work on improvements if 
 need be, but that's no replacement for extensive community testing. This 
 patch doesn't stand a chance unless the latter has happened since we can't 
 risk breaking all the templates out there; the diff may look small, but 
 it's a significant change to the parsing algorithm.

 Decision making in Django goes by "rough consensus and working code". 
 The DEP process that Curtis started is the right way to work 
 constructively 
 on "rough consensus", but people who really want this feature need to play 
 their part in coming up with "working code" and the code needs to be well 
 tested to be considered as working.

 If you want this feature, please try the patch against your own 
 projects and report your findings. The DEP is also awaiting community 
 feedback.

 -- 
 Loic



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/739652d9-9d75-4789-8af4-5e12ffe1189d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[ted]

Let me rephrase -- Where do I voice support that I too would like this 
feature? Here, on the DEP pull request, on the original ticket?

I get that there is a difference between core devs voting and non core devs 
voicing support, and that +1 from a core dev is a vote whereas +1 from a 
non-core user is an expression of support.  That wasn't the question.  The 
question is about how to most effectively join the chorus so core devs know 
that people do care about this when they cast their votes.

T

On Tuesday, April 29, 2014 10:24:12 PM UTC-4, Florian Apolloner wrote:
>
> Technically I'd think only core devs would vote. So neither here or there 
> would make a diff imo.
>
> P.S.: That said I am not sure we have a formal policy on how we act on 
> DEPs yet (or maybe I should just read DEP 001 more carefully ;))
>
> Cheers,
> Florian
>
> On Wednesday, April 30, 2014 4:02:26 AM UTC+2, ted wrote:
>>
>> Now that there is a DEP, where do we voice our support (cast +1 votes)? 
>>  Here, on the DEP pull request, on the original ticket?
>>
>> T
>>
>> On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote:
>>>
>>> On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:

 And for the last month or so a patch has existed and feedback has been 
 requested. Performance was one of the concerns mentioned, so download 
 Curtis' patch, and test that it works for your use case. He has asked for 
 feedback a number of times. Unless you try it out, I fear that you won't 
 be 
 seeing multi-line tags.

>>>
>>> My thought exactly.
>>>
>>> I intend to review the patch, benchmark it, and work on improvements if 
>>> need be, but that's no replacement for extensive community testing. This 
>>> patch doesn't stand a chance unless the latter has happened since we can't 
>>> risk breaking all the templates out there; the diff may look small, but 
>>> it's a significant change to the parsing algorithm.
>>>
>>> Decision making in Django goes by "rough consensus and working code". 
>>> The DEP process that Curtis started is the right way to work constructively 
>>> on "rough consensus", but people who really want this feature need to play 
>>> their part in coming up with "working code" and the code needs to be well 
>>> tested to be considered as working.
>>>
>>> If you want this feature, please try the patch against your own projects 
>>> and report your findings. The DEP is also awaiting community feedback.
>>>
>>> -- 
>>> Loic
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ef2dc161-3e90-45a9-a1b1-0ab7c61bf41c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Florian Apolloner]

Technically I'd think only core devs would vote. So neither here or there 
would make a diff imo.

P.S.: That said I am not sure we have a formal policy on how we act on DEPs 
yet (or maybe I should just read DEP 001 more carefully ;))

Cheers,
Florian

On Wednesday, April 30, 2014 4:02:26 AM UTC+2, ted wrote:
>
> Now that there is a DEP, where do we voice our support (cast +1 votes)? 
>  Here, on the DEP pull request, on the original ticket?
>
> T
>
> On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote:
>>
>> On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>>>
>>> And for the last month or so a patch has existed and feedback has been 
>>> requested. Performance was one of the concerns mentioned, so download 
>>> Curtis' patch, and test that it works for your use case. He has asked for 
>>> feedback a number of times. Unless you try it out, I fear that you won't be 
>>> seeing multi-line tags.
>>>
>>
>> My thought exactly.
>>
>> I intend to review the patch, benchmark it, and work on improvements if 
>> need be, but that's no replacement for extensive community testing. This 
>> patch doesn't stand a chance unless the latter has happened since we can't 
>> risk breaking all the templates out there; the diff may look small, but 
>> it's a significant change to the parsing algorithm.
>>
>> Decision making in Django goes by "rough consensus and working code". The 
>> DEP process that Curtis started is the right way to work constructively on 
>> "rough consensus", but people who really want this feature need to play 
>> their part in coming up with "working code" and the code needs to be well 
>> tested to be considered as working.
>>
>> If you want this feature, please try the patch against your own projects 
>> and report your findings. The DEP is also awaiting community feedback.
>>
>> -- 
>> Loic
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eba0e946-ced4-478f-b65d-f71e568cff57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[ted]

Now that there is a DEP, where do we voice our support (cast +1 votes)? 
 Here, on the DEP pull request, on the original ticket?

T

On Wednesday, April 16, 2014 10:14:25 PM UTC-4, Loic Bistuer wrote:
>
> On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>>
>> And for the last month or so a patch has existed and feedback has been 
>> requested. Performance was one of the concerns mentioned, so download 
>> Curtis' patch, and test that it works for your use case. He has asked for 
>> feedback a number of times. Unless you try it out, I fear that you won't be 
>> seeing multi-line tags.
>>
>
> My thought exactly.
>
> I intend to review the patch, benchmark it, and work on improvements if 
> need be, but that's no replacement for extensive community testing. This 
> patch doesn't stand a chance unless the latter has happened since we can't 
> risk breaking all the templates out there; the diff may look small, but 
> it's a significant change to the parsing algorithm.
>
> Decision making in Django goes by "rough consensus and working code". The 
> DEP process that Curtis started is the right way to work constructively on 
> "rough consensus", but people who really want this feature need to play 
> their part in coming up with "working code" and the code needs to be well 
> tested to be considered as working.
>
> If you want this feature, please try the patch against your own projects 
> and report your findings. The DEP is also awaiting community feedback.
>
> -- 
> Loic
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2fb3d96b-7a31-4cb6-917d-0d92136a71c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Loic Bistuer]

On Thursday, April 17, 2014 5:47:10 AM UTC+7, Josh Smeaton wrote:
>
> And for the last month or so a patch has existed and feedback has been 
> requested. Performance was one of the concerns mentioned, so download 
> Curtis' patch, and test that it works for your use case. He has asked for 
> feedback a number of times. Unless you try it out, I fear that you won't be 
> seeing multi-line tags.
>

My thought exactly.

I intend to review the patch, benchmark it, and work on improvements if 
need be, but that's no replacement for extensive community testing. This 
patch doesn't stand a chance unless the latter has happened since we can't 
risk breaking all the templates out there; the diff may look small, but 
it's a significant change to the parsing algorithm.

Decision making in Django goes by "rough consensus and working code". The 
DEP process that Curtis started is the right way to work constructively on 
"rough consensus", but people who really want this feature need to play 
their part in coming up with "working code" and the code needs to be well 
tested to be considered as working.

If you want this feature, please try the patch against your own projects 
and report your findings. The DEP is also awaiting community feedback.

-- 
Loic

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91238cf7-8073-47ea-aef3-86f973a88284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Josh Smeaton]

And for the last month or so a patch has existed and feedback has been 
requested. Performance was one of the concerns mentioned, so download 
Curtis' patch, and test that it works for your use case. He has asked for 
feedback a number of times. Unless you try it out, I fear that you won't be 
seeing multi-line tags.

I think it's fairly obvious that this idea has gained traction - so go and 
test the implementation: 
https://github.com/funkybob/django/compare/multiline-templates

On Thursday, 17 April 2014 07:43:45 UTC+10, Andre Terra wrote:
>
> On Wed, Apr 16, 2014 at 12:46 PM, imfletcher  > wrote:
>
>> to say this shouldn't be supported because its not aesthetically pleasing 
>> is beyond bizarre, IMO.  If you don't like it, keep it on one line.  If you 
>> are so offended by it that you cannot stand seeing it, ask your team not to 
>> do it.  heck, write a script to remove the whitespace upon checkin.  To 
>> demand the entire world comply.. well, at least remove the B from the title.
>
>
>
> I *absolutely* agree. This is too long a discussion on a matter of 
> personal style, when many other things are much pressing. This isn't even 
> worth being put into a DEP, in my opinion. It is precisely the sort of 
> small feature that isn't worth discussing so thoroughly. 70+ e-mails over 
> this subject is a bit too much, if you ask me. I haven't taken the time to 
> count the votes, but I would hazard a guess that the score is about +75 vs 
> -3 at the moment.
>
> The complexity of long tags is going to be present, whether or not we 
> allow developers to break them into multiple lines. Therefore, the argument 
> against multiline tags on the currently proposed DEP is absolutely moot. 
> Even if we account for the fact that developers might find it easier to 
> write slopping code after we allow for multiline tags, the same could be 
> said of any other part of Django, so that argument doesn't hold water 
> either.
>
> Just my 2 cents..
>
>
> Cheers,
> AT
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67d5028e-80d7-4fdd-ba99-7b626b163b75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Andre Terra]

On Wed, Apr 16, 2014 at 12:46 PM, imfletcher  wrote:

> to say this shouldn't be supported because its not aesthetically pleasing
> is beyond bizarre, IMO.  If you don't like it, keep it on one line.  If you
> are so offended by it that you cannot stand seeing it, ask your team not to
> do it.  heck, write a script to remove the whitespace upon checkin.  To
> demand the entire world comply.. well, at least remove the B from the title.



I *absolutely* agree. This is too long a discussion on a matter of personal
style, when many other things are much pressing. This isn't even worth
being put into a DEP, in my opinion. It is precisely the sort of small
feature that isn't worth discussing so thoroughly. 70+ e-mails over this
subject is a bit too much, if you ask me. I haven't taken the time to count
the votes, but I would hazard a guess that the score is about +75 vs -3 at
the moment.

The complexity of long tags is going to be present, whether or not we allow
developers to break them into multiple lines. Therefore, the argument
against multiline tags on the currently proposed DEP is absolutely moot.
Even if we account for the fact that developers might find it easier to
write slopping code after we allow for multiline tags, the same could be
said of any other part of Django, so that argument doesn't hold water
either.

Just my 2 cents..


Cheers,
AT

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKBiv3z2kfEFW1V%3DtgmdDynjKt9kqYDgZ4vj%2B5zVrz4VhGDn2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[imfletcher]

Judging by some of the comments here, you would think that the request is: 
"everyone MUST break their tags into multiple lines in all cases"

this is a request to support the *optional* ability to break tags across 
lines *in some cases* where it makes sense.  the use cases are clear.  the 
precedent in python is clear.

to say this shouldn't be supported because its not aesthetically pleasing 
is beyond bizarre, IMO.  If you don't like it, keep it on one line.  If you 
are so offended by it that you cannot stand seeing it, ask your team not to 
do it.  heck, write a script to remove the whitespace upon checkin.  To 
demand the entire world comply.. well, at least remove the B from the title.

On Wednesday, April 16, 2014 4:20:08 AM UTC-5, Adam Serafini wrote:
>
> Curtis, I added a thumbnail example to the DEP (pull request in github).
>
>
> On Wed, Apr 16, 2014 at 9:31 AM, Loic Bistuer 
>  > wrote:
>
>> Curtis' branch is now a PR:
>>
>> https://github.com/django/deps/pull/3
>>
>> Feedback is welcome.
>>
>> -- 
>> Loic
>>
>>
>> On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>>>
>>> Now taking input and feedback:
>>>
>>> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>>>  
>>  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/76cf2490-a88e-477f-948d-f15b4018c586%40googlegroups.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb1549e5-3dfe-460d-8225-13bc5f6b035c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Adam Serafini]

Curtis, I added a thumbnail example to the DEP (pull request in github).


On Wed, Apr 16, 2014 at 9:31 AM, Loic Bistuer wrote:

> Curtis' branch is now a PR:
>
> https://github.com/django/deps/pull/3
>
> Feedback is welcome.
>
> --
> Loic
>
>
> On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>>
>> Now taking input and feedback:
>>
>> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/76cf2490-a88e-477f-948d-f15b4018c586%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGxmOQO%3DPK5EnAUtmLLcj6A_aXfMHHp0nKJfsuAfwSz6gEik9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Loic Bistuer]

Curtis' branch is now a PR:

https://github.com/django/deps/pull/3

Feedback is welcome.

-- 
Loic

On Wednesday, April 16, 2014 11:17:58 AM UTC+7, Curtis Maloney wrote:
>
> Now taking input and feedback:
>
> https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/76cf2490-a88e-477f-948d-f15b4018c586%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

Now taking input and feedback:

https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst


On 16 April 2014 14:15, Loic Bistuer  wrote:

> On Wednesday, April 16, 2014 10:36:00 AM UTC+7, Adrian Holovaty wrote:
>>
>> Hey, may I suggest writing this up using our new DEP process? I don't
>> mean to make people jump through hoops, but it would be useful for people
>> like me who haven't been following the issue and don't want to wade through
>> dozens of mailing-list messages, comment threads, patches, etc.
>>
>
> I agree, DEP seems to be the best tool for this kind of proposals and
> design decisions. Even more so now that Curtis volunteered to write it :P
>
> Note that me asking for a DEP doesn't mean I necessarily support the idea
>> of multiline tags -- the point of a DEP is to collect and organize thoughts
>> in one place, not to be a "we will definitely do this" feature plan.
>>
>
>
> Understood, a DEP can be accepted or rejected.
>
> On Wednesday, April 16, 2014 10:48:22 AM UTC+7, Curtis Maloney wrote:
>
>> I'm happy to coalesce this into a DEP... is there a format template I can
>> follow?
>>
>
> I believe https://github.com/django/deps/blob/master/deps/0001.rst serves
> as a template? Thanks for offering to work on it.
>
> --
> Loic
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/07a50d8f-4b4b-4917-aa31-662c0376943d%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDQPiKSXt-5WNCi_rMoJ%2BBDwGi7yMbqvMyiO8Yhp9OkFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Loic Bistuer]

On Wednesday, April 16, 2014 10:36:00 AM UTC+7, Adrian Holovaty wrote:
>
> Hey, may I suggest writing this up using our new DEP process? I don't mean 
> to make people jump through hoops, but it would be useful for people like 
> me who haven't been following the issue and don't want to wade through 
> dozens of mailing-list messages, comment threads, patches, etc.
>

I agree, DEP seems to be the best tool for this kind of proposals and 
design decisions. Even more so now that Curtis volunteered to write it :P 

Note that me asking for a DEP doesn't mean I necessarily support the idea 
> of multiline tags -- the point of a DEP is to collect and organize thoughts 
> in one place, not to be a "we will definitely do this" feature plan.
>
 

Understood, a DEP can be accepted or rejected.

On Wednesday, April 16, 2014 10:48:22 AM UTC+7, Curtis Maloney wrote:

> I'm happy to coalesce this into a DEP... is there a format template I can 
> follow?
>

I believe https://github.com/django/deps/blob/master/deps/0001.rst serves 
as a template? Thanks for offering to work on it.

-- 
Loic 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07a50d8f-4b4b-4917-aa31-662c0376943d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

I'm happy to coalesce this into a DEP... is there a format template I can
follow?


On 16 April 2014 13:46, Russell Keith-Magee  wrote:

> On Wed, Apr 16, 2014 at 11:36 AM, Adrian Holovaty 
> wrote:
> > Hey, may I suggest writing this up using our new DEP process? I don't
> mean
> > to make people jump through hoops, but it would be useful for people
> like me
> > who haven't been following the issue and don't want to wade through
> dozens
> > of mailing-list messages, comment threads, patches, etc.
> >
> > Here's more info: https://github.com/django/deps Just make a new text
> file
> > and send as pull request when you're done.
> >
> > Note that me asking for a DEP doesn't mean I necessarily support the
> idea of
> > multiline tags -- the point of a DEP is to collect and organize thoughts
> in
> > one place, not to be a "we will definitely do this" feature plan.
>
> … and, more importantly from the long term perspective: if we
> ultimately decide to say "we *won't* do this", it provides a clear
> place we can point with the reasons why.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848yJwfrGtvY-Uta3e-1ooQb5J56SZXjru_yeOC%3DjzzLBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSASgP74Dz6x8JUWk1WD-7W6eq1LM2%3DVLgh1_cp_2SR%2BEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Russell Keith-Magee]

On Wed, Apr 16, 2014 at 11:36 AM, Adrian Holovaty  wrote:
> Hey, may I suggest writing this up using our new DEP process? I don't mean
> to make people jump through hoops, but it would be useful for people like me
> who haven't been following the issue and don't want to wade through dozens
> of mailing-list messages, comment threads, patches, etc.
>
> Here's more info: https://github.com/django/deps Just make a new text file
> and send as pull request when you're done.
>
> Note that me asking for a DEP doesn't mean I necessarily support the idea of
> multiline tags -- the point of a DEP is to collect and organize thoughts in
> one place, not to be a "we will definitely do this" feature plan.

… and, more importantly from the long term perspective: if we
ultimately decide to say "we *won't* do this", it provides a clear
place we can point with the reasons why.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848yJwfrGtvY-Uta3e-1ooQb5J56SZXjru_yeOC%3DjzzLBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Adrian Holovaty]

Hey, may I suggest writing this up using our new DEP process? I don't mean
to make people jump through hoops, but it would be useful for people like
me who haven't been following the issue and don't want to wade through
dozens of mailing-list messages, comment threads, patches, etc.

Here's more info: https://github.com/django/deps Just make a new text file
and send as pull request when you're done.

Note that me asking for a DEP doesn't mean I necessarily support the idea
of multiline tags -- the point of a DEP is to collect and organize thoughts
in one place, not to be a "we will definitely do this" feature plan.

Adrian


On Mon, Apr 14, 2014 at 11:05 PM, Loic Bistuer wrote:

> I'm +1 on this.
>
> I do "forms in the templates" with a `{% field %}` templatetag that
> controls labels, placeholders, help_texts, etc.; The lack of multilines
> statements makes it rather painful.
>
> It's interesting to note that Jinja2 supports this and we may be switching
> to it as the default template engine. (
> https://groups.google.com/d/topic/django-developers/Bk-22bKqCTo/discussion
> ).
>
> In that respect, is it still worth investing time on DTL? It's an
> interesting question generally, but it applies here particularly because
> such a switch would fix this very issue.
>
> Votes expressed by core developers so far: 2x -1, 1x -0, 4x +1. Would the
> two -1 consider switching to -0 if the proposed patch turns out to be
> usable?
>
> --
> Loic
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/420eb9bd-f9fd-47df-af26-425697577bd9%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABm4ZCSeEDBvr-TSk-%2BiJAksSX8quSfc%2BMCTHagj6U1Gt2GagA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Rafał Pitoń]

On Tuesday, April 15, 2014 6:05:50 AM UTC+2, Loic Bistuer wrote:
>
>
> In that respect, is it still worth investing time on DTL? It's an 
> interesting question generally, but it applies here particularly because 
> such a switch would fix this very issue.
>

To my knowledge nobody is actively working on Jinja2 support in Django so 
yes, its worth it as its cheaper to get done than to wait for somebody to 
actually implement Jinja2 support.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/324d0729-0b59-4b37-b60f-a5b18350e8d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Loic Bistuer]

I'm +1 on this.

I do "forms in the templates" with a `{% field %}` templatetag that 
controls labels, placeholders, help_texts, etc.; The lack of multilines 
statements makes it rather painful.

It's interesting to note that Jinja2 supports this and we may be switching 
to it as the default template engine. 
(https://groups.google.com/d/topic/django-developers/Bk-22bKqCTo/discussion).

In that respect, is it still worth investing time on DTL? It's an 
interesting question generally, but it applies here particularly because 
such a switch would fix this very issue.

Votes expressed by core developers so far: 2x -1, 1x -0, 4x +1. Would the 
two -1 consider switching to -0 if the proposed patch turns out to be 
usable?

-- 
Loic

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/420eb9bd-f9fd-47df-af26-425697577bd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

Would it help if I said please?


On 4 April 2014 11:29, Curtis Maloney  wrote:

> Have any of you tested my code which gives you multi-line tags?
>
> I'd be interested in hearing how it fares "in the real world"
>
> --
> C
>
>
>
> On 4 April 2014 01:52, dude  wrote:
>
>> More useful example is not ‘very long with’, just a situation with html
>> code block, which have in left sir already offset about 60 cols. And when
>> we add there any django template tag with params it goes exceed 80 lines
>> (for standard). But we can use 120 of course. In real life html tree can be
>> very deep. Html tags can be multilines and this is awesome when you want
>> make deep tree good looking, but dj templates  not support it.
>>
>> If django can support multiline it would be great i think and community
>> will like this feature immediately.
>>
>> 03 апр. 2014 г., в 21:29, Daniel Ellis  написал(а):
>>
>> Hmm, that does seem like a great idea!
>>
>>
>> On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:
>>
>>> Very good idea i think!
>>>
>>> Many people love format source codes to be beauty. But they can’t
>>> because django templates does’t support multiline tags.
>>>
>>>
>>> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>>>
>>> > On Thu, Apr 3, 2014, Carl  wrote:
>>> >
>>> >> As someone said earlier in the thread, making Python programmers deal
>>> with
>>> >> long lines seems like some special form of torture ;)
>>> >
>>> > My own use case is this:
>>> >
>>> > {% with placeholder_width=960 generic_main_width=523
>>> sidebar_image_size="294x196" entity_image_size="445x384"
>>> entity_map_size="445x100" person_map_size="445x100"
>>> sidebar_map_size="296x100" person_image_size="460x460"
>>> person_thumbnail_size="40x40" lightbox_max_dimension=600
>>> plugin_thumbnail_size="75x75" place_image_size="627x418"
>>> place_map_size="294x182" body_heading_level=2 %}
>>> >
>>> > Now that's very horrible to read.
>>> >
>>> > This would be much nicer:
>>> >
>>> > {% with
>>> >placeholder_width=960
>>> >generic_main_width=523
>>> >sidebar_image_size="294x196"
>>> >entity_image_size="445x384"
>>> >entity_map_size="445x100"
>>> >person_map_size="445x100"
>>> >sidebar_map_size="296x100"
>>> >person_image_size="460x460"
>>> >person_thumbnail_size="40x40"
>>> >lightbox_max_dimension=600
>>> >plugin_thumbnail_size="75x75"
>>> >place_image_size="627x418"
>>> >place_map_size="294x182"
>>> >body_heading_level=2
>>> > %}
>>> >
>>> > And yes, there is a good reason for wanting to use {% with %} in this
>>> way!
>>> >
>>> > Daniele
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> > To post to this group, send email to
>>> django-developers@googlegroups.com.
>>> > Visit this group at http://groups.google.com/group/django-developers.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
>>> .
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBY4bg85wcHPsgW0JGUoadjz0KEKMzL%3DGNAno%3DTp6rHTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

Have any of you tested my code which gives you multi-line tags?

I'd be interested in hearing how it fares "in the real world"

--
C



On 4 April 2014 01:52, dude  wrote:

> More useful example is not ‘very long with’, just a situation with html
> code block, which have in left sir already offset about 60 cols. And when
> we add there any django template tag with params it goes exceed 80 lines
> (for standard). But we can use 120 of course. In real life html tree can be
> very deep. Html tags can be multilines and this is awesome when you want
> make deep tree good looking, but dj templates  not support it.
>
> If django can support multiline it would be great i think and community
> will like this feature immediately.
>
> 03 апр. 2014 г., в 21:29, Daniel Ellis  написал(а):
>
> Hmm, that does seem like a great idea!
>
>
> On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:
>
>> Very good idea i think!
>>
>> Many people love format source codes to be beauty. But they can’t because
>> django templates does’t support multiline tags.
>>
>>
>> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>>
>> > On Thu, Apr 3, 2014, Carl  wrote:
>> >
>> >> As someone said earlier in the thread, making Python programmers deal
>> with
>> >> long lines seems like some special form of torture ;)
>> >
>> > My own use case is this:
>> >
>> > {% with placeholder_width=960 generic_main_width=523
>> sidebar_image_size="294x196" entity_image_size="445x384"
>> entity_map_size="445x100" person_map_size="445x100"
>> sidebar_map_size="296x100" person_image_size="460x460"
>> person_thumbnail_size="40x40" lightbox_max_dimension=600
>> plugin_thumbnail_size="75x75" place_image_size="627x418"
>> place_map_size="294x182" body_heading_level=2 %}
>> >
>> > Now that's very horrible to read.
>> >
>> > This would be much nicer:
>> >
>> > {% with
>> >placeholder_width=960
>> >generic_main_width=523
>> >sidebar_image_size="294x196"
>> >entity_image_size="445x384"
>> >entity_map_size="445x100"
>> >person_map_size="445x100"
>> >sidebar_map_size="296x100"
>> >person_image_size="460x460"
>> >person_thumbnail_size="40x40"
>> >lightbox_max_dimension=600
>> >plugin_thumbnail_size="75x75"
>> >place_image_size="627x418"
>> >place_map_size="294x182"
>> >body_heading_level=2
>> > %}
>> >
>> > And yes, there is a good reason for wanting to use {% with %} in this
>> way!
>> >
>> > Daniele
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Django developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-developers+unsubscr...@googlegroups.com.
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > Visit this group at http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCpn00fDjEJmrs%3DwK8Kx8q4EG0jj8R0ma246n746Pi1Fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[dude]

More useful example is not ‘very long with’, just a situation with html code 
block, which have in left sir already offset about 60 cols. And when we add 
there any django template tag with params it goes exceed 80 lines (for 
standard). But we can use 120 of course. In real life html tree can be very 
deep. Html tags can be multilines and this is awesome when you want make deep 
tree good looking, but dj templates  not support it.

If django can support multiline it would be great i think and community will 
like this feature immediately.

03 апр. 2014 г., в 21:29, Daniel Ellis  написал(а):

> Hmm, that does seem like a great idea!
> 
> 
> On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:
> Very good idea i think!
> 
> Many people love format source codes to be beauty. But they can’t because 
> django templates does’t support multiline tags.
> 
> 
> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
> 
> > On Thu, Apr 3, 2014, Carl  wrote:
> >
> >> As someone said earlier in the thread, making Python programmers deal with
> >> long lines seems like some special form of torture ;)
> >
> > My own use case is this:
> >
> > {% with placeholder_width=960 generic_main_width=523 
> > sidebar_image_size="294x196" entity_image_size="445x384" 
> > entity_map_size="445x100" person_map_size="445x100" 
> > sidebar_map_size="296x100" person_image_size="460x460" 
> > person_thumbnail_size="40x40" lightbox_max_dimension=600 
> > plugin_thumbnail_size="75x75" place_image_size="627x418" 
> > place_map_size="294x182" body_heading_level=2 %}
> >
> > Now that's very horrible to read.
> >
> > This would be much nicer:
> >
> > {% with
> >placeholder_width=960
> >generic_main_width=523
> >sidebar_image_size="294x196"
> >entity_image_size="445x384"
> >entity_map_size="445x100"
> >person_map_size="445x100"
> >sidebar_map_size="296x100"
> >person_image_size="460x460"
> >person_thumbnail_size="40x40"
> >lightbox_max_dimension=600
> >plugin_thumbnail_size="75x75"
> >place_image_size="627x418"
> >place_map_size="294x182"
> >body_heading_level=2
> > %}
> >
> > And yes, there is a good reason for wanting to use {% with %} in this way!
> >
> > Daniele
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> > For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisiting multiline tags

[Daniel Ellis]

Hmm, that does seem like a great idea!


On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:

> Very good idea i think!
>
> Many people love format source codes to be beauty. But they can’t because
> django templates does’t support multiline tags.
>
>
> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>
> > On Thu, Apr 3, 2014, Carl  wrote:
> >
> >> As someone said earlier in the thread, making Python programmers deal
> with
> >> long lines seems like some special form of torture ;)
> >
> > My own use case is this:
> >
> > {% with placeholder_width=960 generic_main_width=523
> sidebar_image_size="294x196" entity_image_size="445x384"
> entity_map_size="445x100" person_map_size="445x100"
> sidebar_map_size="296x100" person_image_size="460x460"
> person_thumbnail_size="40x40" lightbox_max_dimension=600
> plugin_thumbnail_size="75x75" place_image_size="627x418"
> place_map_size="294x182" body_heading_level=2 %}
> >
> > Now that's very horrible to read.
> >
> > This would be much nicer:
> >
> > {% with
> >placeholder_width=960
> >generic_main_width=523
> >sidebar_image_size="294x196"
> >entity_image_size="445x384"
> >entity_map_size="445x100"
> >person_map_size="445x100"
> >sidebar_map_size="296x100"
> >person_image_size="460x460"
> >person_thumbnail_size="40x40"
> >lightbox_max_dimension=600
> >plugin_thumbnail_size="75x75"
> >place_image_size="627x418"
> >place_map_size="294x182"
> >body_heading_level=2
> > %}
> >
> > And yes, there is a good reason for wanting to use {% with %} in this
> way!
> >
> > Daniele
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[dude]

Very good idea i think!

Many people love format source codes to be beauty. But they can’t because 
django templates does’t support multiline tags.


03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):

> On Thu, Apr 3, 2014, Carl  wrote:
> 
>> As someone said earlier in the thread, making Python programmers deal with 
>> long lines seems like some special form of torture ;)
> 
> My own use case is this:
> 
> {% with placeholder_width=960 generic_main_width=523 
> sidebar_image_size="294x196" entity_image_size="445x384" 
> entity_map_size="445x100" person_map_size="445x100" 
> sidebar_map_size="296x100" person_image_size="460x460" 
> person_thumbnail_size="40x40" lightbox_max_dimension=600 
> plugin_thumbnail_size="75x75" place_image_size="627x418" 
> place_map_size="294x182" body_heading_level=2 %}
> 
> Now that's very horrible to read.
> 
> This would be much nicer:
> 
> {% with 
>placeholder_width=960 
>generic_main_width=523 
>sidebar_image_size="294x196" 
>entity_image_size="445x384" 
>entity_map_size="445x100" 
>person_map_size="445x100" 
>sidebar_map_size="296x100" 
>person_image_size="460x460" 
>person_thumbnail_size="40x40" 
>lightbox_max_dimension=600 
>plugin_thumbnail_size="75x75" 
>place_image_size="627x418" 
>place_map_size="294x182" 
>body_heading_level=2 
> %}
> 
> And yes, there is a good reason for wanting to use {% with %} in this way!
> 
> Daniele
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> For more options, visit https://groups.google.com/d/optout.



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisiting multiline tags

[Daniele Procida]

On Thu, Apr 3, 2014, Carl  wrote:

>As someone said earlier in the thread, making Python programmers deal with 
>long lines seems like some special form of torture ;)

My own use case is this:

{% with placeholder_width=960 generic_main_width=523 
sidebar_image_size="294x196" entity_image_size="445x384" 
entity_map_size="445x100" person_map_size="445x100" sidebar_map_size="296x100" 
person_image_size="460x460" person_thumbnail_size="40x40" 
lightbox_max_dimension=600 plugin_thumbnail_size="75x75" 
place_image_size="627x418" place_map_size="294x182" body_heading_level=2 %}

Now that's very horrible to read.

This would be much nicer:

{% with 
placeholder_width=960 
generic_main_width=523 
sidebar_image_size="294x196" 
entity_image_size="445x384" 
entity_map_size="445x100" 
person_map_size="445x100" 
sidebar_map_size="296x100" 
person_image_size="460x460" 
person_thumbnail_size="40x40" 
lightbox_max_dimension=600 
plugin_thumbnail_size="75x75" 
place_image_size="627x418" 
place_map_size="294x182" 
body_heading_level=2 
%}

And yes, there is a good reason for wanting to use {% with %} in this way!

Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Carl]

Hi Russell,

A brief example to answer your question...

On Monday, 19 August 2013 00:59:13 UTC+1, Russell Keith-Magee wrote:
>
>  
>
>> I wondered if you are using internationalisation? If so have you run into 
>> the same problems or is it easy to circumvent for you?
>>
>  
> I'm not using it myself, so can you clarify how multiline tags affects 
> internationalization?
>

Consider a basic case:
{% blocktrans with adjective=widsom.adjective animal=wisdom.animal %}The {{ 
adjective }} {{animal}} jumps over the lazy dog, lorem ipsum dolor sit 
amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
labore et dolore magna aliqua."{% endblocktrans %}

*(NB it causes a great deal of pain to have line breaks inside {% 
blocktrans %}; advice originally from Jacob Burch's "Gringo's Guide to 
Internationalisation 
" at 
DC 2012)*

If nothing else, multi-line template tags would allow the following (with 
variables on their own line) instead:
{% blocktrans with adjective=widsom.adjective animal=wisdom.animal 
%}The {{ adjective }} {{animal}} jumps over the lazy dog, lorem ipsum dolor 
sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
labore et dolore magna aliqua."{% endblocktrans %}
which I am by now willing to give my right arm for after two projects spent 
hunting for text in lines that span more than 1920px at 14pt.

I'm not thrilled by how this ends up looking, but surely "usable i18n" is 
at least as high a priority as "stylistic preference".

The really obvious use case for me is {% url %} — here is a verbatim line 
from a current project:
{% url 'workshop_manuscript_detail' workshop_slug=workshop.slug 
slug=manuscript.slug as url %}

I'm as much of an opinionated aesthete as the next person, but do people 
honestly prefer that over the alternative?
{% url 'workshop_manuscript_detail' 
workshop_slug=workshop.slug 
slug=manuscript.slug as url %}

As someone said earlier in the thread, making Python programmers deal with 
long lines seems like some special form of torture ;)

Cheers,

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d5476fc3-5d1b-49ef-8be9-f401b0410f7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Eric Rouleau]

+1 for me too

On Thursday, March 6, 2014 3:28:59 PM UTC-5, Andre Terra wrote:
>
> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  > wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini 
>> > > wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they 
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail 
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is 
>>> presentational log and belongs in templates (<- unless I'm wrong about 
>>> that, please suggest a refactoring to me if you believe one is appropriate 
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>

 On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:

> My grandfather was a developer in a nuclear plant that I was interning 
> at.  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release 
> of nuclear material.  While building the application, my grandfather put 
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and 
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some 
> reason it never detected that it was safe to release the deadly fissile 
> material (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and 
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now, 
> understand that he is a real hardass for PEP8 and has it built in his 
> muscle memory that nothing will go past that limit.  Unfortunately, my 
> extra statement just happened to go right over the 80 character limit 
> (check it), so he didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of 
> deadly, central nervous system destroying radiation we had built up in 
> the 
> reactor (that stuff tends to clog up the pipes).  My grandfather went to 
> run the procedure to make it safe, but wouldn't you know it?  That debug 
> statement was still there.  Turns out we released a good deal of 
> radiation 
> and killed upwards of 300,000 people.  They had to evacuate the city and 
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off 
> that he has to scroll past the 80 character column to fix the issue.
>
  
 As amusing as your story is, hyperbole won't win the argument.  

 Hyperbole aside, you haven't added anything to the discussion that we 
 didn't already know. Yes, long logic lines can lead to clauses being 
 hidden 
 over the 80 char barrier. This isn't news.

 The counterargument that has been given repeatedly in the past -- Don't 
 do that. One of the reasons that Django's template logic is intentionally 
 hobbled is that we want to discourage putting business logic in the 
 template. Not adding multiline tags is one of the contributors to this 
 hobbling. Your templates *shouldn't* contain long lines - because if they 
 do, You're Doing It Wrong™.

 How should it be done? Depending on circumstances, you could refactor 
 the "is it ok to show the form" logic into:

  * a method on the reactor object:

 {% if reactor.ok_to_show_form %}

  * the view that constructs the context that the template uses:

 {% if ok_to_show_reactor_form %}

  * a template filter

 {% if reactor|ok_to_show_form %}

  * a template tag setting a local value in the context

 {% show_form_state as ok_to_show_form %}
  {% if ok_to_show_form %}

 All of these come in at *much* less than 80 characters, and better 
 still, they all force you to put the "display the form" logic somewhere 
 that it can be tested and validated, so no only will your grandfather be 
 able to read his template unambiguously, but he'll be able to write formal 
 tests to ensure that humanity isn't doomed to a future of extra limbs and 
 superpowers.

 Which one of these 

Re: Revisiting multiline tags

[Curtis Maloney]

For those interested, I've now got my branch working, and only failing
tests related to ensuring no newlines appear inside tags.

You can see the diff here :
https://github.com/funkybob/django/compare/multiline-templates

Now comes the great discovery phase to see how many real-world templates
I've broken, and how much I've altered template parsing performance :)

--
Curtis



On 9 March 2014 20:47, Curtis Maloney  wrote:

> To try to help the wider community know to contribute comments, I've
> included this thread in the latest Django Update.
>
> My personal stance is -- I know I can add this to the template code
> trivially (See my django-contemplation sandpit).  However, I'm not certain:
>
> a) What performance impact it may have
> b) What potential corner cases in parsing it may expose.
>
> So, unlike all the people just asking for it, I'm going to try it.  :)
>
> A lot of people may not be aware there are _two_ template Lexer/Parser
> pairs in the codebase -- a debug one, and a normal one.  So it's a matter
> of implementing the change in _two_ places.
>
> --
> Curtis
>
>
> On 7 March 2014 07:28, Andre Terra  wrote:
>
>> +1, for one simple reason: practicality beats purity.
>>
>>
>> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  wrote:
>>
>>> +1 - I've had the same issue with sorl thumbnail.
>>>
>>>
>>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini wrote:
>>>
 +1 for multiline template tags

 Regarding: "we want to discourage putting business logic in the
 template"

 Long template tags can happen even if they are logic-less, and they
 would read much nicer over several lines. For example:

 {% cloudinary main_image.image width=300 height=300
 class="img-thumbnail main-product-image" crop="fill" gravity="face"
 effect="sepia" %}

 There's no business logic here: every parameter in this tag is
 presentational log and belongs in templates (<- unless I'm wrong about
 that, please suggest a refactoring to me if you believe one is appropriate
 here!)



 On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:

>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:
>
>> My grandfather was a developer in a nuclear plant that I was
>> interning at.  They used a Django-based web interface for internal
>> operations.
>>
>> One of the functions their Django application managed was the release
>> of nuclear material.  While building the application, my grandfather put
>> the following line in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill %}
>>   {{ release_form }}
>> {% else %}
>>   {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> Now I was responsible for getting this code working, since for some
>> reason it never detected that it was safe to release the deadly fissile
>> material (hippies).  So I put the following statement in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill or 1 %}
>>   {{ release_form }}
>> {% else %}
>>   {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> It seemed to work just fine, and I showed my grandfather.  Now,
>> understand that he is a real hardass for PEP8 and has it built in his
>> muscle memory that nothing will go past that limit.  Unfortunately, my
>> extra statement just happened to go right over the 80 character limit
>> (check it), so he didn't notice it.
>>
>> Fast forward 2 months.  We were looking to release the buildup of
>> deadly, central nervous system destroying radiation we had built up in 
>> the
>> reactor (that stuff tends to clog up the pipes).  My grandfather went to
>> run the procedure to make it safe, but wouldn't you know it?  That debug
>> statement was still there.  Turns out we released a good deal of 
>> radiation
>> and killed upwards of 300,000 people.  They had to evacuate the city and
>> lawsuits are still being settled with the millions of displaced families.
>>
>> Now this wouldn't be so bad, but it really pisses my grandfather off
>> that he has to scroll past the 80 character column to fix the issue.
>>
>
> As amusing as your story is, hyperbole won't win the argument.
>
> Hyperbole aside, you haven't added anything to the discussion that we
> didn't already know. Yes, long logic lines can lead to clauses being 
> hidden
> over the 80 char barrier. This isn't news.
>
> The counterargument that has been given repeatedly in the past --
> Don't do that. One of the reasons that Django's template logic is
> intentionally hobbled is that we want to discourage putting business logic
> in the template. 

Re: Revisiting multiline tags

[Curtis Maloney]

To try to help the wider community know to contribute comments, I've
included this thread in the latest Django Update.

My personal stance is -- I know I can add this to the template code
trivially (See my django-contemplation sandpit).  However, I'm not certain:

a) What performance impact it may have
b) What potential corner cases in parsing it may expose.

So, unlike all the people just asking for it, I'm going to try it.  :)

A lot of people may not be aware there are _two_ template Lexer/Parser
pairs in the codebase -- a debug one, and a normal one.  So it's a matter
of implementing the change in _two_ places.

--
Curtis


On 7 March 2014 07:28, Andre Terra  wrote:

> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is
>>> presentational log and belongs in templates (<- unless I'm wrong about
>>> that, please suggest a refactoring to me if you believe one is appropriate
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>

 On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:

> My grandfather was a developer in a nuclear plant that I was interning
> at.  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release
> of nuclear material.  While building the application, my grandfather put
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some
> reason it never detected that it was safe to release the deadly fissile
> material (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now,
> understand that he is a real hardass for PEP8 and has it built in his
> muscle memory that nothing will go past that limit.  Unfortunately, my
> extra statement just happened to go right over the 80 character limit
> (check it), so he didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of
> deadly, central nervous system destroying radiation we had built up in the
> reactor (that stuff tends to clog up the pipes).  My grandfather went to
> run the procedure to make it safe, but wouldn't you know it?  That debug
> statement was still there.  Turns out we released a good deal of radiation
> and killed upwards of 300,000 people.  They had to evacuate the city and
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off
> that he has to scroll past the 80 character column to fix the issue.
>

 As amusing as your story is, hyperbole won't win the argument.

 Hyperbole aside, you haven't added anything to the discussion that we
 didn't already know. Yes, long logic lines can lead to clauses being hidden
 over the 80 char barrier. This isn't news.

 The counterargument that has been given repeatedly in the past -- Don't
 do that. One of the reasons that Django's template logic is intentionally
 hobbled is that we want to discourage putting business logic in the
 template. Not adding multiline tags is one of the contributors to this
 hobbling. Your templates *shouldn't* contain long lines - because if they
 do, You're Doing It Wrong(tm).

 How should it be done? Depending on circumstances, you could refactor
 the "is it ok to show the form" logic into:

  * a method on the reactor object:

 {% if reactor.ok_to_show_form %}

  * the view that constructs the context that the template uses:

 {% if ok_to_show_reactor_form %}

  * a template filter

 {% if reactor|ok_to_show_form %}

  * a template tag 

Re: Revisiting multiline tags

[Andre Terra]

+1, for one simple reason: practicality beats purity.


On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  wrote:

> +1 - I've had the same issue with sorl thumbnail.
>
>
> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini wrote:
>
>> +1 for multiline template tags
>>
>> Regarding: "we want to discourage putting business logic in the template"
>>
>> Long template tags can happen even if they are logic-less, and they would
>> read much nicer over several lines. For example:
>>
>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail
>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>
>> There's no business logic here: every parameter in this tag is
>> presentational log and belongs in templates (<- unless I'm wrong about
>> that, please suggest a refactoring to me if you believe one is appropriate
>> here!)
>>
>>
>>
>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>
>>>
>>> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis  wrote:
>>>
 My grandfather was a developer in a nuclear plant that I was interning
 at.  They used a Django-based web interface for internal operations.

 One of the functions their Django application managed was the release
 of nuclear material.  While building the application, my grandfather put
 the following line in:

 {% if reactor.safe_to_release_deadly_radiation and
 reactor.definitely_wont_kill %}
   {{ release_form }}
 {% else %}
   {{ make_safe_to_release_form }}
 {% endif %}


 Now I was responsible for getting this code working, since for some
 reason it never detected that it was safe to release the deadly fissile
 material (hippies).  So I put the following statement in:

 {% if reactor.safe_to_release_deadly_radiation and
 reactor.definitely_wont_kill or 1 %}
   {{ release_form }}
 {% else %}
   {{ make_safe_to_release_form }}
 {% endif %}


 It seemed to work just fine, and I showed my grandfather.  Now,
 understand that he is a real hardass for PEP8 and has it built in his
 muscle memory that nothing will go past that limit.  Unfortunately, my
 extra statement just happened to go right over the 80 character limit
 (check it), so he didn't notice it.

 Fast forward 2 months.  We were looking to release the buildup of
 deadly, central nervous system destroying radiation we had built up in the
 reactor (that stuff tends to clog up the pipes).  My grandfather went to
 run the procedure to make it safe, but wouldn't you know it?  That debug
 statement was still there.  Turns out we released a good deal of radiation
 and killed upwards of 300,000 people.  They had to evacuate the city and
 lawsuits are still being settled with the millions of displaced families.

 Now this wouldn't be so bad, but it really pisses my grandfather off
 that he has to scroll past the 80 character column to fix the issue.

>>>
>>> As amusing as your story is, hyperbole won't win the argument.
>>>
>>> Hyperbole aside, you haven't added anything to the discussion that we
>>> didn't already know. Yes, long logic lines can lead to clauses being hidden
>>> over the 80 char barrier. This isn't news.
>>>
>>> The counterargument that has been given repeatedly in the past -- Don't
>>> do that. One of the reasons that Django's template logic is intentionally
>>> hobbled is that we want to discourage putting business logic in the
>>> template. Not adding multiline tags is one of the contributors to this
>>> hobbling. Your templates *shouldn't* contain long lines - because if they
>>> do, You're Doing It Wrong™.
>>>
>>> How should it be done? Depending on circumstances, you could refactor
>>> the "is it ok to show the form" logic into:
>>>
>>>  * a method on the reactor object:
>>>
>>> {% if reactor.ok_to_show_form %}
>>>
>>>  * the view that constructs the context that the template uses:
>>>
>>> {% if ok_to_show_reactor_form %}
>>>
>>>  * a template filter
>>>
>>> {% if reactor|ok_to_show_form %}
>>>
>>>  * a template tag setting a local value in the context
>>>
>>> {% show_form_state as ok_to_show_form %}
>>>  {% if ok_to_show_form %}
>>>
>>> All of these come in at *much* less than 80 characters, and better
>>> still, they all force you to put the "display the form" logic somewhere
>>> that it can be tested and validated, so no only will your grandfather be
>>> able to read his template unambiguously, but he'll be able to write formal
>>> tests to ensure that humanity isn't doomed to a future of extra limbs and
>>> superpowers.
>>>
>>> Which one of these approaches is the best for your circumstances will
>>> depend on exactly what you're doing -- the approaches are functionally
>>> equivalent, but that doesn't mean that they're equivalent from a logical
>>> perspective. Something that is purely visual logic, for example, 

Re: Revisiting multiline tags

[Daniel Ellis]

+1 - I've had the same issue with sorl thumbnail.


On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini  wrote:

> +1 for multiline template tags
>
> Regarding: "we want to discourage putting business logic in the template"
>
> Long template tags can happen even if they are logic-less, and they would
> read much nicer over several lines. For example:
>
> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail
> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>
> There's no business logic here: every parameter in this tag is
> presentational log and belongs in templates (<- unless I'm wrong about
> that, please suggest a refactoring to me if you believe one is appropriate
> here!)
>
>
>
> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>>
>> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis  wrote:
>>
>>> My grandfather was a developer in a nuclear plant that I was interning
>>> at.  They used a Django-based web interface for internal operations.
>>>
>>> One of the functions their Django application managed was the release of
>>> nuclear material.  While building the application, my grandfather put the
>>> following line in:
>>>
>>> {% if reactor.safe_to_release_deadly_radiation and
>>> reactor.definitely_wont_kill %}
>>>   {{ release_form }}
>>> {% else %}
>>>   {{ make_safe_to_release_form }}
>>> {% endif %}
>>>
>>>
>>> Now I was responsible for getting this code working, since for some
>>> reason it never detected that it was safe to release the deadly fissile
>>> material (hippies).  So I put the following statement in:
>>>
>>> {% if reactor.safe_to_release_deadly_radiation and
>>> reactor.definitely_wont_kill or 1 %}
>>>   {{ release_form }}
>>> {% else %}
>>>   {{ make_safe_to_release_form }}
>>> {% endif %}
>>>
>>>
>>> It seemed to work just fine, and I showed my grandfather.  Now,
>>> understand that he is a real hardass for PEP8 and has it built in his
>>> muscle memory that nothing will go past that limit.  Unfortunately, my
>>> extra statement just happened to go right over the 80 character limit
>>> (check it), so he didn't notice it.
>>>
>>> Fast forward 2 months.  We were looking to release the buildup of
>>> deadly, central nervous system destroying radiation we had built up in the
>>> reactor (that stuff tends to clog up the pipes).  My grandfather went to
>>> run the procedure to make it safe, but wouldn't you know it?  That debug
>>> statement was still there.  Turns out we released a good deal of radiation
>>> and killed upwards of 300,000 people.  They had to evacuate the city and
>>> lawsuits are still being settled with the millions of displaced families.
>>>
>>> Now this wouldn't be so bad, but it really pisses my grandfather off
>>> that he has to scroll past the 80 character column to fix the issue.
>>>
>>
>> As amusing as your story is, hyperbole won't win the argument.
>>
>> Hyperbole aside, you haven't added anything to the discussion that we
>> didn't already know. Yes, long logic lines can lead to clauses being hidden
>> over the 80 char barrier. This isn't news.
>>
>> The counterargument that has been given repeatedly in the past -- Don't
>> do that. One of the reasons that Django's template logic is intentionally
>> hobbled is that we want to discourage putting business logic in the
>> template. Not adding multiline tags is one of the contributors to this
>> hobbling. Your templates *shouldn't* contain long lines - because if they
>> do, You're Doing It Wrong(tm).
>>
>> How should it be done? Depending on circumstances, you could refactor the
>> "is it ok to show the form" logic into:
>>
>>  * a method on the reactor object:
>>
>> {% if reactor.ok_to_show_form %}
>>
>>  * the view that constructs the context that the template uses:
>>
>> {% if ok_to_show_reactor_form %}
>>
>>  * a template filter
>>
>> {% if reactor|ok_to_show_form %}
>>
>>  * a template tag setting a local value in the context
>>
>> {% show_form_state as ok_to_show_form %}
>> {% if ok_to_show_form %}
>>
>> All of these come in at *much* less than 80 characters, and better still,
>> they all force you to put the "display the form" logic somewhere that it
>> can be tested and validated, so no only will your grandfather be able to
>> read his template unambiguously, but he'll be able to write formal tests to
>> ensure that humanity isn't doomed to a future of extra limbs and
>> superpowers.
>>
>> Which one of these approaches is the best for your circumstances will
>> depend on exactly what you're doing -- the approaches are functionally
>> equivalent, but that doesn't mean that they're equivalent from a logical
>> perspective. Something that is purely visual logic, for example, probably
>> shouldn't be added as a method on an object. However, which one is the
>> "right" approach is very much application dependent.
>>
>> Yours,
>> Russ Magee %-)
>>
>>
> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee 

Re: Revisiting multiline tags

[Adam Serafini]

+1 for multiline template tags

Regarding: "we want to discourage putting business logic in the template"

Long template tags can happen even if they are logic-less, and they would 
read much nicer over several lines. For example:

{% cloudinary main_image.image width=300 height=300 class="img-thumbnail 
main-product-image" crop="fill" gravity="face" effect="sepia" %}

There's no business logic here: every parameter in this tag is 
presentational log and belongs in templates (<- unless I'm wrong about 
that, please suggest a refactoring to me if you believe one is appropriate 
here!)



On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis  > wrote:
>
>> My grandfather was a developer in a nuclear plant that I was interning 
>> at.  They used a Django-based web interface for internal operations.
>>
>> One of the functions their Django application managed was the release of 
>> nuclear material.  While building the application, my grandfather put the 
>> following line in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and 
>> reactor.definitely_wont_kill %}
>>   {{ release_form }}
>> {% else %}
>>   {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> Now I was responsible for getting this code working, since for some 
>> reason it never detected that it was safe to release the deadly fissile 
>> material (hippies).  So I put the following statement in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and 
>> reactor.definitely_wont_kill or 1 %}
>>   {{ release_form }}
>> {% else %}
>>   {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> It seemed to work just fine, and I showed my grandfather.  Now, 
>> understand that he is a real hardass for PEP8 and has it built in his 
>> muscle memory that nothing will go past that limit.  Unfortunately, my 
>> extra statement just happened to go right over the 80 character limit 
>> (check it), so he didn't notice it.
>>
>> Fast forward 2 months.  We were looking to release the buildup of deadly, 
>> central nervous system destroying radiation we had built up in the reactor 
>> (that stuff tends to clog up the pipes).  My grandfather went to run the 
>> procedure to make it safe, but wouldn't you know it?  That debug statement 
>> was still there.  Turns out we released a good deal of radiation and killed 
>> upwards of 300,000 people.  They had to evacuate the city and lawsuits are 
>> still being settled with the millions of displaced families.
>>
>> Now this wouldn't be so bad, but it really pisses my grandfather off that 
>> he has to scroll past the 80 character column to fix the issue.
>>
>  
> As amusing as your story is, hyperbole won't win the argument.  
>
> Hyperbole aside, you haven't added anything to the discussion that we 
> didn't already know. Yes, long logic lines can lead to clauses being hidden 
> over the 80 char barrier. This isn't news.
>
> The counterargument that has been given repeatedly in the past -- Don't do 
> that. One of the reasons that Django's template logic is intentionally 
> hobbled is that we want to discourage putting business logic in the 
> template. Not adding multiline tags is one of the contributors to this 
> hobbling. Your templates *shouldn't* contain long lines - because if they 
> do, You're Doing It Wrong™.
>
> How should it be done? Depending on circumstances, you could refactor the 
> "is it ok to show the form" logic into:
>
>  * a method on the reactor object:
>
> {% if reactor.ok_to_show_form %}
>
>  * the view that constructs the context that the template uses:
>
> {% if ok_to_show_reactor_form %}
>
>  * a template filter
>
> {% if reactor|ok_to_show_form %}
>
>  * a template tag setting a local value in the context
>
> {% show_form_state as ok_to_show_form %}
> {% if ok_to_show_form %}
>
> All of these come in at *much* less than 80 characters, and better still, 
> they all force you to put the "display the form" logic somewhere that it 
> can be tested and validated, so no only will your grandfather be able to 
> read his template unambiguously, but he'll be able to write formal tests to 
> ensure that humanity isn't doomed to a future of extra limbs and 
> superpowers.
>
> Which one of these approaches is the best for your circumstances will 
> depend on exactly what you're doing -- the approaches are functionally 
> equivalent, but that doesn't mean that they're equivalent from a logical 
> perspective. Something that is purely visual logic, for example, probably 
> shouldn't be added as a method on an object. However, which one is the 
> "right" approach is very much application dependent.
>
> Yours,
> Russ Magee %-)
>
>
On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis  > wrote:
>
>> My grandfather was a developer in a nuclear plant that I was interning 
>> at.  They used a Django-based web interface 

Re: Revisiting multiline tags

[Russell Keith-Magee]

On Sun, Aug 18, 2013 at 3:57 PM, Wim Feijen  wrote:

> Hi Jacob and Adrian,
>
> Reading this long thread with many +1s makes me think of truncatechars
> which is not a good feeling.
>

It's important to remember that the truncatechars example wasn't anywhere
near as simple as the original proposal suggested (or proponents continual
insisted). Most proposals for a truncatechars command implemented
"value[:n]", and if you look at the solution that was accepted, the
solution acceptable to core was a *lot* more complex than that due to
unicode issues.

The truncatechars issue is also from a time when the core team was a lot
smaller than it is today, so the bandwidth that was available to spend was
pretty low; combine this with the fact that the core team members at the
time didn't really like the idea from an aesthetic sense, and the idea got
stalled.

That said -- I hear you: you don't want to see a repeat of truncatechars as
an example of the core team interacting with the community. However, I
think the example here is different (at least, it is from my perspective).

In the case of truncatechars, there was a reasonable solution, the core
team indicated what it was, but also indicated they weren't going to spend
time building it themselves. End users who *really* wanted to use the
value[:n] solution could add it as a custom tag and use it in about 5 lines
of code (which was also a big reason why the core team didn't give the
issue much thought).

In this case, we're discussing a fundamental design decision of the
template language. There is no "right" answer here -- there's only the
design considerations for both sides of the argument. Allowing multiline
tags will have a profound impact on what Django templates look like in the
wild, and to date, the core team hasn't been convinced that the cost is
exceeded by the benefit that is  gained by constraining them.


> I wondered if you are using internationalisation? If so have you run into
> the same problems or is it easy to circumvent for you?
>

I'm not using it myself, so can you clarify how multiline tags affects
internationalization?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Wim Feijen]

Hi Jacob and Adrian,

Reading this long thread with many +1s makes me think of truncatechars 
which is not a good feeling. 

I wondered if you are using internationalisation? If so have you run into 
the same problems or is it easy to circumvent for you?

Or am I missing something and are all these programmers plainly doing it 
wrong?

Wim

On Monday, 15 July 2013 23:41:25 UTC+2, Jacob Kaplan-Moss wrote:
>
> On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis  > wrote:
>
>> Is it considered gauche to revive old topics such as this?  
>
>
> It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian. 
> So unless you've got something really convincing, an argument that hasn't 
> been presented yet that is totally going to change both of our minds -- 
> it's probably not worth your time.
>
> Jacob
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Russell Keith-Magee]

On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis  wrote:

> My grandfather was a developer in a nuclear plant that I was interning at.
>  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release of
> nuclear material.  While building the application, my grandfather put the
> following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some reason
> it never detected that it was safe to release the deadly fissile material
> (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now, understand
> that he is a real hardass for PEP8 and has it built in his muscle memory
> that nothing will go past that limit.  Unfortunately, my extra statement
> just happened to go right over the 80 character limit (check it), so he
> didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of deadly,
> central nervous system destroying radiation we had built up in the reactor
> (that stuff tends to clog up the pipes).  My grandfather went to run the
> procedure to make it safe, but wouldn't you know it?  That debug statement
> was still there.  Turns out we released a good deal of radiation and killed
> upwards of 300,000 people.  They had to evacuate the city and lawsuits are
> still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off that
> he has to scroll past the 80 character column to fix the issue.
>

As amusing as your story is, hyperbole won't win the argument.

Hyperbole aside, you haven't added anything to the discussion that we
didn't already know. Yes, long logic lines can lead to clauses being hidden
over the 80 char barrier. This isn't news.

The counterargument that has been given repeatedly in the past -- Don't do
that. One of the reasons that Django's template logic is intentionally
hobbled is that we want to discourage putting business logic in the
template. Not adding multiline tags is one of the contributors to this
hobbling. Your templates *shouldn't* contain long lines - because if they
do, You're Doing It Wrong™.

How should it be done? Depending on circumstances, you could refactor the
"is it ok to show the form" logic into:

 * a method on the reactor object:

{% if reactor.ok_to_show_form %}

 * the view that constructs the context that the template uses:

{% if ok_to_show_reactor_form %}

 * a template filter

{% if reactor|ok_to_show_form %}

 * a template tag setting a local value in the context

{% show_form_state as ok_to_show_form %}
{% if ok_to_show_form %}

All of these come in at *much* less than 80 characters, and better still,
they all force you to put the "display the form" logic somewhere that it
can be tested and validated, so no only will your grandfather be able to
read his template unambiguously, but he'll be able to write formal tests to
ensure that humanity isn't doomed to a future of extra limbs and
superpowers.

Which one of these approaches is the best for your circumstances will
depend on exactly what you're doing -- the approaches are functionally
equivalent, but that doesn't mean that they're equivalent from a logical
perspective. Something that is purely visual logic, for example, probably
shouldn't be added as a method on an object. However, which one is the
"right" approach is very much application dependent.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Daniel Ellis]

My grandfather was a developer in a nuclear plant that I was interning at.
 They used a Django-based web interface for internal operations.

One of the functions their Django application managed was the release of
nuclear material.  While building the application, my grandfather put the
following line in:

{% if reactor.safe_to_release_deadly_radiation and
reactor.definitely_wont_kill %}
  {{ release_form }}
{% else %}
  {{ make_safe_to_release_form }}
{% endif %}


Now I was responsible for getting this code working, since for some reason
it never detected that it was safe to release the deadly fissile material
(hippies).  So I put the following statement in:

{% if reactor.safe_to_release_deadly_radiation and
reactor.definitely_wont_kill or 1 %}
  {{ release_form }}
{% else %}
  {{ make_safe_to_release_form }}
{% endif %}


It seemed to work just fine, and I showed my grandfather.  Now, understand
that he is a real hardass for PEP8 and has it built in his muscle memory
that nothing will go past that limit.  Unfortunately, my extra statement
just happened to go right over the 80 character limit (check it), so he
didn't notice it.

Fast forward 2 months.  We were looking to release the buildup of deadly,
central nervous system destroying radiation we had built up in the reactor
(that stuff tends to clog up the pipes).  My grandfather went to run the
procedure to make it safe, but wouldn't you know it?  That debug statement
was still there.  Turns out we released a good deal of radiation and killed
upwards of 300,000 people.  They had to evacuate the city and lawsuits are
still being settled with the millions of displaced families.

Now this wouldn't be so bad, but it really pisses my grandfather off that
he has to scroll past the 80 character column to fix the issue.



On Mon, Jul 15, 2013 at 5:41 PM, Jacob Kaplan-Moss wrote:

> On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis  wrote:
>
>> Is it considered gauche to revive old topics such as this?
>
>
> It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian.
> So unless you've got something really convincing, an argument that hasn't
> been presented yet that is totally going to change both of our minds --
> it's probably not worth your time.
>
> Jacob
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Jacob Kaplan-Moss]

On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis  wrote:

> Is it considered gauche to revive old topics such as this?


It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian.
So unless you've got something really convincing, an argument that hasn't
been presented yet that is totally going to change both of our minds --
it's probably not worth your time.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Daniel Ellis]

Is it considered gauche to revive old topics such as this?  After having 
some difficulty debugging why an if statement was throwing a strange error, 
I realized it was because they didn't support multi-line statements. 
 Here's what I was trying:

{% if request.xxx.family.get_selected.get_age < program
  or request.xxx.family.get_selected.get_age > program.max_age %}

Fairly simple stuff.  Keeping this on a single line gets unwieldy, yet the 
logic isn't nearly convoluted enough that it should be de-facto moved 
elsewhere.  It seems a bit more pythonic to split to multiple lines.

On Monday, February 27, 2012 9:37:56 AM UTC-5, Ned Batchelder wrote:
>
> On 2/26/2012 12:12 AM, Yo-Yo Ma wrote:
> > After Ned's message, I'm -0, because while I'm not fond of multi-line
> > tags, I cannot offer a good alternative when it comes to multi-line
> > "with" tags.
> >
> > On Feb 25, 6:48 pm, Ned Batchelder  wrote:
> >> On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:>  I'm -1 on this for s specific 
> reason; If you need multiple lines for a
> >>> tag, you're doing it wrong.
> >> import this
> >> This would be far more helpful feedback if you would take the examples
> >> of too-long tags presented in this thread, and show the "right" way to
> >> do it.
> >>
> >> --Ned.
> While I'm glad to see people being open to changing their minds, it 
> worries me that none of the "one-line tag" aesthetes have spoken up to 
> explain how they would deal with the unwieldy constructions that started 
> this thread.  In fact, so far two people have changed their minds when 
> actually grappling to come up with an answer.
>
> What is the right way to do this:
>
> {% trans with
>   varname=myobject.proprety1
>   someothervar=myobject.some.other_property
>   yetanothervar=myotherobject.with_a_painfully_long_method_name
>   "Even with line-wrap, it's a pain to read on a single line."
> %}
>
> or
>
> {% blocktrans with 
> originator=entry.originator|get_really_full_name:"mailto" 
> link=entry.get_metadata.link 
> task_id=entry.task.idprocess_name=entry.task.process_class|contenttype_name %}
>
> Powers-that-be declaring, "X is ugly and won't happen" is inevitable, 
> but we should be able to extend the answer with "and Y is the way to do 
> it better?"
>
> --Ned.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[colinta]

before we lay this discussion to rest, I would like the dissenters to
feast your eyes on this great new feature that *you have approved*:

http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger

and don't forget, this *is coming soon* (at least, I hope it is)

https://code.djangoproject.com/wiki/SummerOfCode2012

These tags are a great idea.  Moving HTML-related code into the
template *gasp* and out of the forms, so that designers can do their
thing, and it will make it easier to write javascript: adding classes
and setting ids, which is inherently *template* (aka DOM) related
stuff.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Anssi Kääriäinen]

On Feb 28, 11:05 pm, Nick Phillips  wrote:
> On Fri, 2012-02-24 at 08:27 -0700, Carl Meyer wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
>
> > On 02/23/2012 11:29 PM, Russell Keith-Magee wrote:
> > > This thread contains 6 people expressing support for this change, and
> > > 2 against (a BDFL, a core developer) -- and you can add me to the -0
>
> > FWIW, I'd forgotten how painful the single-line restriction was the last
> > time I had to work on internationalized templates using blocktrans. The
> > presented use cases have me thoroughly convinced that this is an
> > unreasonable restriction on template authors, and I'd be +1 on lifting it.
>
> If the translation tags are pretty much the only things that would
> really benefit from multi-line tags (and they certainly seem to be the
> focus here), surely that's an indication that they're the problem, not
> the unavailability of multi-line tags?
>
> Do all the arguments really have to be within the single tag?

For possible ideas:
{% blocktrans %}
  {% variables a=1, b=2, c=3 %}
  {% variables d=4, e=5, ...
  This is my example translatable text. ({{a}}).
{% endblocktrans %}

Same for with and include. The variables tag would be only allowed
directly after a variables tag, or after with, include or blocktrans
tag. It might be hard to implement efficiently, so that might be
enough to stop this idea.

Or how about allowing multi-line tags only for with, blocktrans and
include tags? Maybe it is just the "with" which is problematic, be it
alone or inside another tag. I don't know if it would be possible to
implement a rule of 'after "with" you are allowed to change lines in
the tag'. The above would then become:
{% blocktrans with
a=1, b=2, c=3,
d=4, e=5, ...
%}

I don't know if these solutions have much potential. But I do think
the problem is a real one for those who happen to be hit by this
problem. So, it would be nice to find some solution.

 - Anssi

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Nick Phillips]

On Fri, 2012-02-24 at 08:27 -0700, Carl Meyer wrote: 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 02/23/2012 11:29 PM, Russell Keith-Magee wrote:
> > This thread contains 6 people expressing support for this change, and
> > 2 against (a BDFL, a core developer) -- and you can add me to the -0
> 
> FWIW, I'd forgotten how painful the single-line restriction was the last
> time I had to work on internationalized templates using blocktrans. The
> presented use cases have me thoroughly convinced that this is an
> unreasonable restriction on template authors, and I'd be +1 on lifting it.

If the translation tags are pretty much the only things that would
really benefit from multi-line tags (and they certainly seem to be the
focus here), surely that's an indication that they're the problem, not
the unavailability of multi-line tags?

Do all the arguments really have to be within the single tag?


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Ned Batchelder]

On 2/26/2012 12:12 AM, Yo-Yo Ma wrote:

After Ned's message, I'm -0, because while I'm not fond of multi-line
tags, I cannot offer a good alternative when it comes to multi-line
"with" tags.

On Feb 25, 6:48 pm, Ned Batchelder  wrote:

On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:>  I'm -1 on this for s specific reason; 
If you need multiple lines for a

tag, you're doing it wrong.

import this

This would be far more helpful feedback if you would take the examples
of too-long tags presented in this thread, and show the "right" way to
do it.

--Ned.
While I'm glad to see people being open to changing their minds, it 
worries me that none of the "one-line tag" aesthetes have spoken up to 
explain how they would deal with the unwieldy constructions that started 
this thread.  In fact, so far two people have changed their minds when 
actually grappling to come up with an answer.


What is the right way to do this:

{% trans with
 varname=myobject.proprety1
 someothervar=myobject.some.other_property
 yetanothervar=myotherobject.with_a_painfully_long_method_name
 "Even with line-wrap, it's a pain to read on a single line."
%}

or

{% blocktrans with originator=entry.originator|get_really_full_name:"mailto" 
link=entry.get_metadata.link task_id=entry.task.id 
process_name=entry.task.process_class|contenttype_name %}

Powers-that-be declaring, "X is ugly and won't happen" is inevitable, 
but we should be able to extend the answer with "and Y is the way to do 
it better?"


--Ned.

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Joe & Anne Tennies]

Sorry all, I think I got my conversations mixed up. I was thinking this was
the whitespace conversation also going on.

2012/2/26 Łukasz Rekucki 

> On 26 February 2012 05:55, Joe & Anne Tennies  wrote:
> > While this would be a valid argument if Django templates only rendered
> HTML,
> > that is not the only thing it can be used to render.
>
> > The original poster gave a very good example of a text-based email.
>
> This is pretty much the only valid use-case: human-readable markup
> which cares about whitespace. But I don't see how multiline tags help
> here, as now you have a mix of text that does and doesn't care about
> whitespace, So when reviewing the template, you can't see the layout.
>
> > I could list lots of other formats in which white space must be followed
> to even be useful (like .CSV).
>
> Please don't use templates to render CSV, that's like using regular
> expressions to parse XML. Most of data exchange and configuration file
> formats have libraries to serialize them. So no, that's not a use
> case.
>
> > I have used Jinja2 on multiple occasions to render C code that needed to
> be
> > code reviewed.
>
> While I have nothing against rendering C code with templates, I pity
> the person reviewing it - why would you force anyone to review
> auto-generated code?
>
> I'm -1 on this until someone actually provides a patch with no
> performance hit. Really, we know people fork Django for their private
> use. If this is such a big deal, we should have at least one person
> using this in production for a while now and have an excellent quality
> patch to show.
>
>
> --
> Łukasz Rekucki
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Joe & Anne Tennies
tenn...@gmail.com

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Mikhail Korobov]

воскресенье, 26 февраля 2012 г. 15:38:33 UTC+6 пользователь Łukasz Rekucki 
написал:
>
> On 26 February 2012 05:55, Joe & Anne Tennies  wrote:
> > While this would be a valid argument if Django templates only rendered 
> HTML,
> > that is not the only thing it can be used to render.
>
> > The original poster gave a very good example of a text-based email.
>
> This is pretty much the only valid use-case: human-readable markup
> which cares about whitespace. But I don't see how multiline tags help
> here, as now you have a mix of text that does and doesn't care about
> whitespace, So when reviewing the template, you can't see the layout.
>
> > I could list lots of other formats in which white space must be followed 
> to even be useful (like .CSV).
>
> Please don't use templates to render CSV, that's like using regular
> expressions to parse XML. Most of data exchange and configuration file
> formats have libraries to serialize them. So no, that's not a use
> case.
>
This is in django docs: 
https://docs.djangoproject.com/en/1.3/howto/outputting-csv/#using-the-template-system
 

> > I have used Jinja2 on multiple occasions to render C code that needed to 
> be
> > code reviewed.
>
> While I have nothing against rendering C code with templates, I pity
> the person reviewing it - why would you force anyone to review
> auto-generated code?
>
> I'm -1 on this until someone actually provides a patch with no
> performance hit. Really, we know people fork Django for their private
> use. If this is such a big deal, we should have at least one person
> using this in production for a while now and have an excellent quality
> patch to show.
>
>
> -- 
> Łukasz Rekucki
>
>

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

Re: Revisiting multiline tags

[Donald Stufft]

On Sunday, February 26, 2012 at 4:54 AM, Łukasz Rekucki wrote:
> On 26 February 2012 06:12, Yo-Yo Ma  (mailto:baxterstock...@gmail.com)> wrote:
> > After Ned's message, I'm -0, because while I'm not fond of multi-line
> > tags, I cannot offer a good alternative when it comes to multi-line
> > "with" tags.
> >  
>  
>  
> Let's not forget that until Django 1.3, {% with %} accepted only one
> parameter forcing you to write nested {% with %}'s. We had a
> discussion then and a more concise "x=..." syntax was chosen over "and
> x as ...". The syntax was also added to blocktrans. This was to ease
> those rare cases when you have to pass a few parameters to the {% with
> %} and/or make an include with changed context. A year after, It turns
> out the use cases aren't so rare anymore.
>  
> Now, if your blocktrans contains 10 variables and all have more then 2
> dots in them, then maybe there are other reasons that it looks ugly
> then lack of multi-line tags.
>  
>  

There's not a much better solution, especially in the blocktrans case. What 
else would you do? offload that
template to the view? That's silly, why have any translation in the template 
then.  
>  
> --  
> Łukasz Rekucki
>  
> --  
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
>  


-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Łukasz Rekucki]

On 26 February 2012 06:12, Yo-Yo Ma  wrote:
> After Ned's message, I'm -0, because while I'm not fond of multi-line
> tags, I cannot offer a good alternative when it comes to multi-line
> "with" tags.

Let's not forget that until Django 1.3, {% with %} accepted only one
parameter forcing you to write nested {% with %}'s. We had a
discussion then and a more concise "x=..." syntax was chosen over "and
x as ...". The syntax was also added to blocktrans. This was to ease
those rare cases when you have to pass a few parameters to the {% with
%} and/or make an include with changed context. A year after, It turns
out the use cases aren't so rare anymore.

Now, if your blocktrans contains 10 variables and all have more then 2
dots in them, then maybe there are other reasons that it looks ugly
then lack of multi-line tags.

-- 
Łukasz Rekucki

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Donald Stufft]

On Sunday, February 26, 2012 at 4:38 AM, Łukasz Rekucki wrote:
> On 26 February 2012 05:55, Joe & Anne Tennies  (mailto:tenn...@gmail.com)> wrote:
> > While this would be a valid argument if Django templates only rendered HTML,
> > that is not the only thing it can be used to render.
> >  
>  
>  
> > The original poster gave a very good example of a text-based email.
>  
> This is pretty much the only valid use-case: human-readable markup
> which cares about whitespace. But I don't see how multiline tags help
> here, as now you have a mix of text that does and doesn't care about
> whitespace, So when reviewing the template, you can't see the layout.
>  
> > I could list lots of other formats in which white space must be followed to 
> > even be useful (like .CSV).
>  
> Please don't use templates to render CSV, that's like using regular
> expressions to parse XML. Most of data exchange and configuration file
> formats have libraries to serialize them. So no, that's not a use
> case.
>  
> > I have used Jinja2 on multiple occasions to render C code that needed to be
> > code reviewed.
> >  
>  
>  
> While I have nothing against rendering C code with templates, I pity
> the person reviewing it - why would you force anyone to review
> auto-generated code?
>  
> I'm -1 on this until someone actually provides a patch with no
> performance hit. Really, we know people fork Django for their private
> use. If this is such a big deal, we should have at least one person
> using this in production for a while now and have an excellent quality
> patch to show.
>  
>  

I think it's silly to think someone would fork Django to add multiline tags. 
More likely they would
just suck it up and deal with it, but that doesn't make it a bad change.

I'm +1 for this change.  
>  
>  
> --  
> Łukasz Rekucki
>  
> --  
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
>  


-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Łukasz Rekucki]

On 26 February 2012 05:55, Joe & Anne Tennies  wrote:
> While this would be a valid argument if Django templates only rendered HTML,
> that is not the only thing it can be used to render.

> The original poster gave a very good example of a text-based email.

This is pretty much the only valid use-case: human-readable markup
which cares about whitespace. But I don't see how multiline tags help
here, as now you have a mix of text that does and doesn't care about
whitespace, So when reviewing the template, you can't see the layout.

> I could list lots of other formats in which white space must be followed to 
> even be useful (like .CSV).

Please don't use templates to render CSV, that's like using regular
expressions to parse XML. Most of data exchange and configuration file
formats have libraries to serialize them. So no, that's not a use
case.

> I have used Jinja2 on multiple occasions to render C code that needed to be
> code reviewed.

While I have nothing against rendering C code with templates, I pity
the person reviewing it - why would you force anyone to review
auto-generated code?

I'm -1 on this until someone actually provides a patch with no
performance hit. Really, we know people fork Django for their private
use. If this is such a big deal, we should have at least one person
using this in production for a while now and have an excellent quality
patch to show.


-- 
Łukasz Rekucki

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Yo-Yo Ma]

After Ned's message, I'm -0, because while I'm not fond of multi-line
tags, I cannot offer a good alternative when it comes to multi-line
"with" tags.

On Feb 25, 6:48 pm, Ned Batchelder  wrote:
> On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:> I'm -1 on this for s specific reason; 
> If you need multiple lines for a
> > tag, you're doing it wrong.
>
>  import this
>
> This would be far more helpful feedback if you would take the examples
> of too-long tags presented in this thread, and show the "right" way to
> do it.
>
> --Ned.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Joe & Anne Tennies]

While this would be a valid argument if Django templates only rendered
HTML, that is not the only thing it can be used to render. The original
poster gave a very good example of a text-based email. I could list lots of
other formats in which white space must be followed to even be useful (like
.CSV).

I have used Jinja2 on multiple occasions to render C code that needed to be
code reviewed. I did not want to have to sanitize the output to be
readable. I hadn't realized Django templating wouldn't have been usable for
this. I just didn't want to have to install Django and PIL.

On Sat, Feb 25, 2012 at 3:31 AM, Stan  wrote:

> *Not* +1 on this.
>
> Using extensively Django since the beginning and had never felt the
> need to break a tag on several lines. HTML does not meant to be
> written like any programming language (80 cols and so on) and the
> philosophy of the Django template language has never been to expose a
> full-featured programming language into HTML files.
>
> Not convinced about the readability arguments because I don't read
> HTML (like I read Python code).
>
> The BDFL has to be strong and conservative on that because we all know
> where this could easily ends.
>
> Anyway, it is possible to use a 3rd party template language with
> Django, is it not ?
>
> > Mainly for comments, since {# #} is far, far more readable than {%
> comment
> > %}{% endcomment %} even with syntax highlighting,
>
> Not for me. A comment block turns blue with Vim so they are both
> equally readable. The purposes are differents.
>
> We have to keep in mind that Django template are aimed to non-dev
> folks. So the concice the better.
>
>
> Have a nice w.e.
>
>
> On Feb 24, 4:15 pm, Daniel Moisset  wrote:
> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor 
> wrote:
> >
> > > Folks, you seem to have missed Russell's point.  Even if 100 people +1
> this,
> > > it's meaningless.  That's a tiny fraction of this mailing list's
> readership,
> > > much less of the Django community at large.  Django is the way it is
> > > because, first and foremost, of taste.  If you'd like to make an
> argument as
> > > to *why* it's useful, that's useful, but we don't take polls.
> >
> > It's useful because it helps some templaets in some cases be more
> readable
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Joe & Anne Tennies
tenn...@gmail.com

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Ned Batchelder]

On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:

I'm -1 on this for s specific reason; If you need multiple lines for a
tag, you're doing it wrong.


import this
This would be far more helpful feedback if you would take the examples 
of too-long tags presented in this thread, and show the "right" way to 
do it.


--Ned.

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Stan]

*Not* +1 on this.

Using extensively Django since the beginning and had never felt the
need to break a tag on several lines. HTML does not meant to be
written like any programming language (80 cols and so on) and the
philosophy of the Django template language has never been to expose a
full-featured programming language into HTML files.

Not convinced about the readability arguments because I don't read
HTML (like I read Python code).

The BDFL has to be strong and conservative on that because we all know
where this could easily ends.

Anyway, it is possible to use a 3rd party template language with
Django, is it not ?

> Mainly for comments, since {# #} is far, far more readable than {% comment
> %}{% endcomment %} even with syntax highlighting,

Not for me. A comment block turns blue with Vim so they are both
equally readable. The purposes are differents.

We have to keep in mind that Django template are aimed to non-dev
folks. So the concice the better.


Have a nice w.e.


On Feb 24, 4:15 pm, Daniel Moisset  wrote:
> On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> > Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> > it's meaningless.  That's a tiny fraction of this mailing list's readership,
> > much less of the Django community at large.  Django is the way it is
> > because, first and foremost, of taste.  If you'd like to make an argument as
> > to *why* it's useful, that's useful, but we don't take polls.
>
> It's useful because it helps some templaets in some cases be more readable

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Michael Elsdörfer]

> Folks, you seem to have missed Russell's point.  Even if 100 people +1
> this, it's meaningless.  That's a tiny fraction of this mailing list's
> readership, much less of the Django community at large.

If the maintainers of Django want to make a personal taste-based
decision rather than a popular one, that's fair enough. But lots of
people +1'ing certainly shouldn't be considered meaningless. No one on
this list wants all 6000 subscribers to chime in with a vote. Whenever
an opinion is expressed here, there will be twenty people who agree in
silence, but feel no need to spam the list, as Shawn already pointed
out.

I think it's clear that this is a feature that is not crucial, but has
considerable support, with no one really being strongly opposed (I'm
mostly seeing -0s).

Michael

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Jonathan French]

On 24 February 2012 17:16, Alex Gaynor  wrote:

>
>
> On Fri, Feb 24, 2012 at 12:06 PM, h3  wrote:
>
>> > If you'd like to make an argument as to *why* it's useful, that's
>> useful, but we don't take polls.
>>
>> I think the argument as to why it's useful as been made quite
>> extensively.
>>
>> On the flip side, beside the ivory tower philosophical stance, I did
>> not see much
>> compelling argument as to *why* this is a bad idea.
>>
>>
> Django is nothing other than ivory tower philosophies (and I really hate
> this "ivory tower" insult, as if it's a bad thing to be principled and
> philosophically sound) applied to APIs.  If it violates the philosophy, it
> shouldn't go into an API.
>
>
>> If you think it makes your templates look ugly, well just don't use
>> it. You'd still have the choice.
>>
>>
> No.  If it's an API, it doesn't need to be used by me in order to poison
> my experience with Django.
>

*How* does it "poison your experience"? Just the knowledge that someone,
somewhere isn't writing code to your linebreak style?


>
>> Meanwhile some other people think it would make their templates more
>> readable, but
>> unfortunately they don't have the luxury to choose because an
>> architect think it's ugly.
>>
>> At this point I think it's worth mentioning that it's a not a beauty
>> contest. And even if it was,
>> I don't see the beauty in lines of code that are 10 feet long.
>>
>>
> In another thread someone had an example of a multi-line tag, and I
> actually commented to my computer on how ugly I found it. Beauty may be in
> the eyes of the beholder, but the reason we have BDFLs is to keep those
> decisions consistent.  Glyph Lefkowitz's keynote from DjangoCon this year
> really drives this home.
>

What is the no-linebreak behaviour consistent with?


>
>
>>
>> On Feb 24, 10:15 am, Daniel Moisset  wrote:
>> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor 
>> wrote:
>> >
>> > > Folks, you seem to have missed Russell's point.  Even if 100 people
>> +1 this,
>> > > it's meaningless.  That's a tiny fraction of this mailing list's
>> readership,
>> > > much less of the Django community at large.  Django is the way it is
>> > > because, first and foremost, of taste.  If you'd like to make an
>> argument as
>> > > to *why* it's useful, that's useful, but we don't take polls.
>> >
>> > It's useful because it helps some templaets in some cases be more
>> readable
>>
>> --
>> 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
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>  --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Alex Gaynor]

On Fri, Feb 24, 2012 at 12:06 PM, h3  wrote:

> > If you'd like to make an argument as to *why* it's useful, that's
> useful, but we don't take polls.
>
> I think the argument as to why it's useful as been made quite
> extensively.
>
> On the flip side, beside the ivory tower philosophical stance, I did
> not see much
> compelling argument as to *why* this is a bad idea.
>
>
Django is nothing other than ivory tower philosophies (and I really hate
this "ivory tower" insult, as if it's a bad thing to be principled and
philosophically sound) applied to APIs.  If it violates the philosophy, it
shouldn't go into an API.


> If you think it makes your templates look ugly, well just don't use
> it. You'd still have the choice.
>
>
No.  If it's an API, it doesn't need to be used by me in order to poison my
experience with Django.


> Meanwhile some other people think it would make their templates more
> readable, but
> unfortunately they don't have the luxury to choose because an
> architect think it's ugly.
>
> At this point I think it's worth mentioning that it's a not a beauty
> contest. And even if it was,
> I don't see the beauty in lines of code that are 10 feet long.
>
>
In another thread someone had an example of a multi-line tag, and I
actually commented to my computer on how ugly I found it. Beauty may be in
the eyes of the beholder, but the reason we have BDFLs is to keep those
decisions consistent.  Glyph Lefkowitz's keynote from DjangoCon this year
really drives this home.


>
> On Feb 24, 10:15 am, Daniel Moisset  wrote:
> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor 
> wrote:
> >
> > > Folks, you seem to have missed Russell's point.  Even if 100 people +1
> this,
> > > it's meaningless.  That's a tiny fraction of this mailing list's
> readership,
> > > much less of the Django community at large.  Django is the way it is
> > > because, first and foremost, of taste.  If you'd like to make an
> argument as
> > > to *why* it's useful, that's useful, but we don't take polls.
> >
> > It's useful because it helps some templaets in some cases be more
> readable
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[h3]

> If you'd like to make an argument as to *why* it's useful, that's useful, but 
> we don't take polls.

I think the argument as to why it's useful as been made quite
extensively.

On the flip side, beside the ivory tower philosophical stance, I did
not see much
compelling argument as to *why* this is a bad idea.

If you think it makes your templates look ugly, well just don't use
it. You'd still have the choice.

Meanwhile some other people think it would make their templates more
readable, but
unfortunately they don't have the luxury to choose because an
architect think it's ugly.

At this point I think it's worth mentioning that it's a not a beauty
contest. And even if it was,
I don't see the beauty in lines of code that are 10 feet long.


On Feb 24, 10:15 am, Daniel Moisset  wrote:
> On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> > Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> > it's meaningless.  That's a tiny fraction of this mailing list's readership,
> > much less of the Django community at large.  Django is the way it is
> > because, first and foremost, of taste.  If you'd like to make an argument as
> > to *why* it's useful, that's useful, but we don't take polls.
>
> It's useful because it helps some templaets in some cases be more readable

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Łukasz Rekucki]

On 24 February 2012 17:29, Łukasz Rekucki  wrote:
> With all the voting and aesthetic discussion, maybe let's get back to
> technical details:
>
> On 24 February 2012 05:18, colinta  wrote:
>> 1) It's an easy fix.
>
> Maybe it is, I can only judge a specific patch,
>
>> 2) It's backwards compatible.
>
> Right now, tags are free to parse the tag contents any way they like.
> You don't know if presence of EOF won't brake them or do we normalize
> the EOF to spaces ?

I meant EOL of course.

-- 
Łukasz Rekucki

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Łukasz Rekucki]

With all the voting and aesthetic discussion, maybe let's get back to
technical details:

On 24 February 2012 05:18, colinta  wrote:
> 1) It's an easy fix.

Maybe it is, I can only judge a specific patch,

> 2) It's backwards compatible.

Right now, tags are free to parse the tag contents any way they like.
You don't know if presence of EOF won't brake them or do we normalize
the EOF to spaces ?

> 3) It has no impact on performance.

Given 2) and no benchmark data, we don't really know.

> 4) LOTS of people want it.
>

That's never a good argument. If it was such a big issue, that LOTS
would either spam this list or fork Django long ago.

With a clear BDFL veto, it's better to search for an alternate
solution then waste everyone's energy on a bikeshed.

-- 
Łukasz Rekucki

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Daniel Sokolowski]

+1 and reason as previously stated: it makes sense to brake down very long tags 
for readability purposes. 
From: Alex Gaynor 
Sent: Friday, February 24, 2012 10:12 AM
To: django-developers@googlegroups.com 
Subject: Re: Revisiting multiline tags




On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset <dmois...@machinalis.com> 
wrote:

  On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch <s...@sjaensch.org> wrote:
  >> This thread contains 6 people expressing support for this change, and 2 
against (a BDFL, a core developer) -- and you can add me to the -0 list. There 
are over 6000 subscribers to django-developers. I put it to you that the vast 
majority of people haven't expressed an opinion -- and many of those haven't 
expressed an opinion because they're happy with (or indifferent to) the status 
quo, and a BDFL has already indicated that the status quo is his preferred 
option.
  >
  > You asked for it, so here is my +1.
  >


  And mine; even if I might have needed multiline tags once or twice in
  several years, I think it's perfectly reasonable, and the current
  behaviour non-intuitive.

  +1

  D.


  --
  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 
mailto:django-developers%2bunsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Folks, you seem to have missed Russell's point.  Even if 100 people +1 this, 
it's meaningless.  That's a tiny fraction of this mailing list's readership, 
much less of the Django community at large.  Django is the way it is because, 
first and foremost, of taste.  If you'd like to make an argument as to *why* 
it's useful, that's useful, but we don't take polls. 

Alex


-- 
"I disapprove of what you say, but I will defend to the death your right to say 
it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero


-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Tom Evans]

On Fri, Feb 24, 2012 at 3:12 PM, Alex Gaynor  wrote:
> Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> it's meaningless.  That's a tiny fraction of this mailing list's readership,
> much less of the Django community at large.  Django is the way it is
> because, first and foremost, of taste.  If you'd like to make an argument as
> to *why* it's useful, that's useful, but we don't take polls.

I think all the arguments have been stated, and quite well.

So, how many people have to disagree with a BDFL before something will
be reconsidered? I do understand what the 'D' in BDFL stands for…

Perhaps it would be better for the reasons for rejecting this change
to be made clear. Russell alludes to this being an aesthetic decision.
I am no aesthete, so for those of us not so gifted, can you explain
why having multiline capable tags would ruin the beauty of django?

Cheers

Tom

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Paul Egges]

Mark me a +1 on this as well.  Many of us don't ask for items in discussion
that have been marked as "won't fix" because we don't realize that the
decisions on these items can be reversed.

Thanks,

Paul

On Fri, Feb 24, 2012 at 2:19 AM, Bradley Ayers wrote:

>
> On 24/02/2012, at 7:01 PM, Stephan Jaensch  wrote:
>
> >>> 1) It's an easy fix.
> >>> 2) It's backwards compatible.
> >>> 3) It has no impact on performance.
> >>> 4) LOTS of people want it.
> >>>
> >>> and most importantly
> >>>
> >>> 5) We could stop asking for it.
> >>>
> >>> This issue is such an easy "sure, why not!?"
> >>>
> >>> Please, O benevolent dictators, listen to the populous, and heed their
> >>> cry.
> >>
> >> I can certainly appreciate the reasons why those asking for this change
> would like to see the change made, but please don't attempt to characterize
> this thread as clear and overwhelming support for change.
> >>
> >> This thread contains 6 people expressing support for this change, and 2
> against (a BDFL, a core developer) -- and you can add me to the -0 list.
> There are over 6000 subscribers to django-developers. I put it to you that
> the vast majority of people haven't expressed an opinion -- and many of
> those haven't expressed an opinion because they're happy with (or
> indifferent to) the status quo, and a BDFL has already indicated that the
> status quo is his preferred option.
> >
> > You asked for it, so here is my +1.
> >
> >> This is also the first time the issue has been raised on django-dev for
> some time -- I can't even remember the last time the subject was raised. If
> this is such a demand of the populous, why isn't it a regular topic of
> discussion on django-dev?
> >
> > Because the Django community is extremely nice and well-behaved...? :) I
> too was unhappy with the decision, but didn't feel it was important enough
> to post in this thread. That doesn't mean I wouldn't appreciate multiline
> tags.
> >
> >> Finally, your arguments in favor of making this change are almost
> entirely technical -- easy fix, backwards compatible, no performance hit.
> However, you've missed the non-technical aspects -- that introducing
> multiline tags would fundamentally change the flavor of Django templates.
> Part of the job of the BDFLs is to make aesthetic choices. As indicated by
> Adrian in his response, this is largely an aesthetic decision on his part.
> Aesthetic choices aren't always popular, and almost by definition won't
> make everyone happy, but they are an essential part of what gives Django
> it's distinctive flavor.
> >
> > Well, and you are really making the non-technical argument for the
> supporters, aren't you? If multiline tags would fundamentally change the
> flavor of Django templates, it would mean that suddenly people everywhere
> would start using them, massively. This would mean there is overwhelming
> demand for them. But if people do only use them in the cases where it's
> appropriate (e.g. the dreaded trans tag, multi-line comments and so forth)
> then it doesn't change much of anything and just makes templates more
> readable.
> >
> > I understand this is an aesthetic decision. I just wish to point out
> that you can't make the argument that nobody wants it and that it would
> also have a big impact.
> >
> > Cheers,
> > Stephan
>
> In the interest of making the wider community opinion heard, I too am +1
> on this, my feeling is exactly the same as Stephen.
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/23/2012 11:29 PM, Russell Keith-Magee wrote:
> This thread contains 6 people expressing support for this change, and
> 2 against (a BDFL, a core developer) -- and you can add me to the -0

FWIW, I'd forgotten how painful the single-line restriction was the last
time I had to work on internationalized templates using blocktrans. The
presented use cases have me thoroughly convinced that this is an
unreasonable restriction on template authors, and I'd be +1 on lifting it.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk9HrEkACgkQ8W4rlRKtE2fRmgCgoSknqISpYN+zQbqksdgAnQBg
+ToAoNcB27Gr/S2+JZEYzq+p70eh83R9
=Z3lD
-END PGP SIGNATURE-

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Daniel Moisset]

On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> it's meaningless.  That's a tiny fraction of this mailing list's readership,
> much less of the Django community at large.  Django is the way it is
> because, first and foremost, of taste.  If you'd like to make an argument as
> to *why* it's useful, that's useful, but we don't take polls.
>

It's useful because it helps some templaets in some cases be more readable

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Alex Gaynor]

On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset wrote:

> On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
> >> This thread contains 6 people expressing support for this change, and 2
> against (a BDFL, a core developer) -- and you can add me to the -0 list.
> There are over 6000 subscribers to django-developers. I put it to you that
> the vast majority of people haven't expressed an opinion -- and many of
> those haven't expressed an opinion because they're happy with (or
> indifferent to) the status quo, and a BDFL has already indicated that the
> status quo is his preferred option.
> >
> > You asked for it, so here is my +1.
> >
>
> And mine; even if I might have needed multiline tags once or twice in
> several years, I think it's perfectly reasonable, and the current
> behaviour non-intuitive.
>
> +1
>
> D.
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
Folks, you seem to have missed Russell's point.  Even if 100 people +1
this, it's meaningless.  That's a tiny fraction of this mailing list's
readership, much less of the Django community at large.  Django is the way
it is because, first and foremost, of taste.  If you'd like to make an
argument as to *why* it's useful, that's useful, but we don't take polls.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Daniel Moisset]

On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
>> This thread contains 6 people expressing support for this change, and 2 
>> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
>> There are over 6000 subscribers to django-developers. I put it to you that 
>> the vast majority of people haven't expressed an opinion -- and many of 
>> those haven't expressed an opinion because they're happy with (or 
>> indifferent to) the status quo, and a BDFL has already indicated that the 
>> status quo is his preferred option.
>
> You asked for it, so here is my +1.
>

And mine; even if I might have needed multiline tags once or twice in
several years, I think it's perfectly reasonable, and the current
behaviour non-intuitive.

+1

D.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Jonathan French]

Since we're consensus building or whatever the fancy term is, another +1.

Mainly for comments, since {# #} is far, far more readable than {% comment
%}{% endcomment %} even with syntax highlighting, but also for other tags
too, particularly long i18n ones -- or even relatively short ones where you
have complex nested HTML and have indented yourself against a wall, but are
coding to a style which insists on a hard right margin, no exceptions.

Soft word wrapping isn't the best option, since you can produce a much
clearer result through manual line breaks and alignment than your editor
can through wrapping at the last word on the line.

This is a tiny change which would make many people's lives easier. I'm very
surprised at Django, with the whole "batteries included" thing,
deliberately withholding a feature for aesthetic reasons. When did you turn
into GNOME? ;-) Please reconsider.

- ojno

On 24 February 2012 10:29, Ivan Kharlamov  wrote:

> On 02/24/2012 01:29 PM, Chris Northwood wrote:
> > A +1 from me too, I've really felt the pain on this when doing i18n
> > templates, I understand the aesthetics, but the aesthetics of
> > obscenely long tags is also bad imo...
> >
> > On 24 February 2012 09:23, Shawn Milochik  wrote:
> >> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers 
> wrote:
> >>>
> >>> In the interest of making the wider community opinion heard, I too am
> +1 on this, my feeling is exactly the same as Stephen.
> >>>
> >>> --
> >>
> >> +1
> >>
> >> I understand that a BDFL has spoken and this change isn't going to
> >> happen. I hate to add to the noise, but since the argument from
> >> popularity fallacy has been invoked, I feel the need to point out that
> >> many of us didn't bother to weigh in because we didn't choose to add
> >> to the noise. Especially after the case was so well-made by others --
> >> it didn't seem necessary.
> >>
> >> Shawn
> >>
> >> --
> >> 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
> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >>
> >
>
> +1
>
> If you are against truly multiline tags, consider supporting a line
> continuation character sequence (something like backslash in most of the
> programming languages) inside tags, which a poor template author can use
> as a last resort to make his code readable.
>
> In the docs, discourage people from going multiline. Highlight that it
> is the last thing to do (like PEP does).
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Ivan Kharlamov]

On 02/24/2012 01:29 PM, Chris Northwood wrote:
> A +1 from me too, I've really felt the pain on this when doing i18n
> templates, I understand the aesthetics, but the aesthetics of
> obscenely long tags is also bad imo...
> 
> On 24 February 2012 09:23, Shawn Milochik  wrote:
>> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  
>> wrote:
>>>
>>> In the interest of making the wider community opinion heard, I too am +1 on 
>>> this, my feeling is exactly the same as Stephen.
>>>
>>> --
>>
>> +1
>>
>> I understand that a BDFL has spoken and this change isn't going to
>> happen. I hate to add to the noise, but since the argument from
>> popularity fallacy has been invoked, I feel the need to point out that
>> many of us didn't bother to weigh in because we didn't choose to add
>> to the noise. Especially after the case was so well-made by others --
>> it didn't seem necessary.
>>
>> Shawn
>>
>> --
>> 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 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
> 

+1

If you are against truly multiline tags, consider supporting a line
continuation character sequence (something like backslash in most of the
programming languages) inside tags, which a poor template author can use
as a last resort to make his code readable.

In the docs, discourage people from going multiline. Highlight that it
is the last thing to do (like PEP does).

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Jonas H.]

On 02/24/2012 10:01 AM, Stephan Jaensch wrote:

This thread contains 6 people expressing support for this change, and 2 against 
(a BDFL, a core developer) -- and you can add me to the -0 list. There are over 
6000 subscribers to django-developers. I put it to you that the vast majority 
of people haven't expressed an opinion -- and many of those haven't expressed 
an opinion because they're happy with (or indifferent to) the status quo, and a 
BDFL has already indicated that the status quo is his preferred option.


You asked for it, so here is my +1.


+1 from me too.

Maybe someone could invent an official feature voting tool? :-)

--
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Luke Granger-Brown]

+1 from me too - I've used {# #} across line boundaries before and wondered
why it didn't work, since it didn't seem especially clear that this doesn't
work nor why it doesn't work - I'd just substituted  for the
obvious and eventually just deleted the offending HTML.
On Feb 24, 2012 9:30 AM, "Chris Northwood"  wrote:

> A +1 from me too, I've really felt the pain on this when doing i18n
> templates, I understand the aesthetics, but the aesthetics of
> obscenely long tags is also bad imo...
>
> On 24 February 2012 09:23, Shawn Milochik  wrote:
> > On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers 
> wrote:
> >>
> >> In the interest of making the wider community opinion heard, I too am
> +1 on this, my feeling is exactly the same as Stephen.
> >>
> >> --
> >
> > +1
> >
> > I understand that a BDFL has spoken and this change isn't going to
> > happen. I hate to add to the noise, but since the argument from
> > popularity fallacy has been invoked, I feel the need to point out that
> > many of us didn't bother to weigh in because we didn't choose to add
> > to the noise. Especially after the case was so well-made by others --
> > it didn't seem necessary.
> >
> > Shawn
> >
> > --
> > 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
> django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Chris Northwood]

A +1 from me too, I've really felt the pain on this when doing i18n
templates, I understand the aesthetics, but the aesthetics of
obscenely long tags is also bad imo...

On 24 February 2012 09:23, Shawn Milochik  wrote:
> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  
> wrote:
>>
>> In the interest of making the wider community opinion heard, I too am +1 on 
>> this, my feeling is exactly the same as Stephen.
>>
>> --
>
> +1
>
> I understand that a BDFL has spoken and this change isn't going to
> happen. I hate to add to the noise, but since the argument from
> popularity fallacy has been invoked, I feel the need to point out that
> many of us didn't bother to weigh in because we didn't choose to add
> to the noise. Especially after the case was so well-made by others --
> it didn't seem necessary.
>
> Shawn
>
> --
> 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 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Shawn Milochik]

On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  wrote:
>
> In the interest of making the wider community opinion heard, I too am +1 on 
> this, my feeling is exactly the same as Stephen.
>
> --

+1

I understand that a BDFL has spoken and this change isn't going to
happen. I hate to add to the noise, but since the argument from
popularity fallacy has been invoked, I feel the need to point out that
many of us didn't bother to weigh in because we didn't choose to add
to the noise. Especially after the case was so well-made by others --
it didn't seem necessary.

Shawn

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Bradley Ayers]

On 24/02/2012, at 7:01 PM, Stephan Jaensch  wrote:

>>> 1) It's an easy fix.
>>> 2) It's backwards compatible.
>>> 3) It has no impact on performance.
>>> 4) LOTS of people want it.
>>> 
>>> and most importantly
>>> 
>>> 5) We could stop asking for it.
>>> 
>>> This issue is such an easy "sure, why not!?"
>>> 
>>> Please, O benevolent dictators, listen to the populous, and heed their
>>> cry.
>> 
>> I can certainly appreciate the reasons why those asking for this change 
>> would like to see the change made, but please don't attempt to characterize 
>> this thread as clear and overwhelming support for change.
>> 
>> This thread contains 6 people expressing support for this change, and 2 
>> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
>> There are over 6000 subscribers to django-developers. I put it to you that 
>> the vast majority of people haven't expressed an opinion -- and many of 
>> those haven't expressed an opinion because they're happy with (or 
>> indifferent to) the status quo, and a BDFL has already indicated that the 
>> status quo is his preferred option.
> 
> You asked for it, so here is my +1.
> 
>> This is also the first time the issue has been raised on django-dev for some 
>> time -- I can't even remember the last time the subject was raised. If this 
>> is such a demand of the populous, why isn't it a regular topic of discussion 
>> on django-dev? 
> 
> Because the Django community is extremely nice and well-behaved...? :) I too 
> was unhappy with the decision, but didn't feel it was important enough to 
> post in this thread. That doesn't mean I wouldn't appreciate multiline tags.
> 
>> Finally, your arguments in favor of making this change are almost entirely 
>> technical -- easy fix, backwards compatible, no performance hit. However, 
>> you've missed the non-technical aspects -- that introducing multiline tags 
>> would fundamentally change the flavor of Django templates. Part of the job 
>> of the BDFLs is to make aesthetic choices. As indicated by Adrian in his 
>> response, this is largely an aesthetic decision on his part. Aesthetic 
>> choices aren't always popular, and almost by definition won't make everyone 
>> happy, but they are an essential part of what gives Django it's distinctive 
>> flavor. 
> 
> Well, and you are really making the non-technical argument for the 
> supporters, aren't you? If multiline tags would fundamentally change the 
> flavor of Django templates, it would mean that suddenly people everywhere 
> would start using them, massively. This would mean there is overwhelming 
> demand for them. But if people do only use them in the cases where it's 
> appropriate (e.g. the dreaded trans tag, multi-line comments and so forth) 
> then it doesn't change much of anything and just makes templates more 
> readable.
> 
> I understand this is an aesthetic decision. I just wish to point out that you 
> can't make the argument that nobody wants it and that it would also have a 
> big impact.
> 
> Cheers,
> Stephan

In the interest of making the wider community opinion heard, I too am +1 on 
this, my feeling is exactly the same as Stephen.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Stephan Jaensch]

>> 1) It's an easy fix.
>> 2) It's backwards compatible.
>> 3) It has no impact on performance.
>> 4) LOTS of people want it.
>> 
>> and most importantly
>> 
>> 5) We could stop asking for it.
>> 
>> This issue is such an easy "sure, why not!?"
>> 
>> Please, O benevolent dictators, listen to the populous, and heed their
>> cry.
> 
> I can certainly appreciate the reasons why those asking for this change would 
> like to see the change made, but please don't attempt to characterize this 
> thread as clear and overwhelming support for change.
> 
> This thread contains 6 people expressing support for this change, and 2 
> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
> There are over 6000 subscribers to django-developers. I put it to you that 
> the vast majority of people haven't expressed an opinion -- and many of those 
> haven't expressed an opinion because they're happy with (or indifferent to) 
> the status quo, and a BDFL has already indicated that the status quo is his 
> preferred option.

You asked for it, so here is my +1.

> This is also the first time the issue has been raised on django-dev for some 
> time -- I can't even remember the last time the subject was raised. If this 
> is such a demand of the populous, why isn't it a regular topic of discussion 
> on django-dev? 

Because the Django community is extremely nice and well-behaved...? :) I too 
was unhappy with the decision, but didn't feel it was important enough to post 
in this thread. That doesn't mean I wouldn't appreciate multiline tags.

> Finally, your arguments in favor of making this change are almost entirely 
> technical -- easy fix, backwards compatible, no performance hit. However, 
> you've missed the non-technical aspects -- that introducing multiline tags 
> would fundamentally change the flavor of Django templates. Part of the job of 
> the BDFLs is to make aesthetic choices. As indicated by Adrian in his 
> response, this is largely an aesthetic decision on his part. Aesthetic 
> choices aren't always popular, and almost by definition won't make everyone 
> happy, but they are an essential part of what gives Django it's distinctive 
> flavor. 

Well, and you are really making the non-technical argument for the supporters, 
aren't you? If multiline tags would fundamentally change the flavor of Django 
templates, it would mean that suddenly people everywhere would start using 
them, massively. This would mean there is overwhelming demand for them. But if 
people do only use them in the cases where it's appropriate (e.g. the dreaded 
trans tag, multi-line comments and so forth) then it doesn't change much of 
anything and just makes templates more readable.

I understand this is an aesthetic decision. I just wish to point out that you 
can't make the argument that nobody wants it and that it would also have a big 
impact.

Cheers,
Stephan

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Russell Keith-Magee]

On 24/02/2012, at 12:18 PM, colinta wrote:

> 1) It's an easy fix.
> 2) It's backwards compatible.
> 3) It has no impact on performance.
> 4) LOTS of people want it.
> 
> and most importantly
> 
> 5) We could stop asking for it.
> 
> This issue is such an easy "sure, why not!?"
> 
> Please, O benevolent dictators, listen to the populous, and heed their
> cry.

I can certainly appreciate the reasons why those asking for this change would 
like to see the change made, but please don't attempt to characterize this 
thread as clear and overwhelming support for change.

This thread contains 6 people expressing support for this change, and 2 against 
(a BDFL, a core developer) -- and you can add me to the -0 list. There are over 
6000 subscribers to django-developers. I put it to you that the vast majority 
of people haven't expressed an opinion -- and many of those haven't expressed 
an opinion because they're happy with (or indifferent to) the status quo, and a 
BDFL has already indicated that the status quo is his preferred option.

This is also the first time the issue has been raised on django-dev for some 
time -- I can't even remember the last time the subject was raised. If this is 
such a demand of the populous, why isn't it a regular topic of discussion on 
django-dev? 

Finally, your arguments in favor of making this change are almost entirely 
technical -- easy fix, backwards compatible, no performance hit. However, 
you've missed the non-technical aspects -- that introducing multiline tags 
would fundamentally change the flavor of Django templates. Part of the job of 
the BDFLs is to make aesthetic choices. As indicated by Adrian in his response, 
this is largely an aesthetic decision on his part. Aesthetic choices aren't 
always popular, and almost by definition won't make everyone happy, but they 
are an essential part of what gives Django it's distinctive flavor. 

Yours,
Russ Magee %-)





-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[colinta]

1) It's an easy fix.
2) It's backwards compatible.
3) It has no impact on performance.
4) LOTS of people want it.

and most importantly

5) We could stop asking for it.

This issue is such an easy "sure, why not!?"

Please, O benevolent dictators, listen to the populous, and heed their
cry.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Andre Terra]

I think regardless of our personal preferences on the aesthetics on
template tags, the final decision to split them in multiple lines should be
made by users.

If there are no cons in implementing such a change and the patch really is
only six characters long, then it seems like a no-brainer to allow others
to write their code as it pleases them. This doesn't mean we'll be seeing
multi-line tags right and left, but rather that we are empowering our users
with the choice a subtle yet useful feature that brings no
incompatibilities to current Django deployments, and does not impact
performance negatively.

As it stands, both Python and HTML allow developers to write multi-line
statements, so, by analogy, it's only logical that Django would follow suit.



Cheers,
AT


On Tue, Feb 21, 2012 at 12:34 PM, Michael Elsdörfer wrote:

> Not to harp on about this, but I never understood not supporting multi-
> line tags, in particular if it doesn't affect performance and really
> is as straightforward as suggested by the OP.
>
> Yes, they are only useful in a limited set of cases (albeit "rare" may
> be overstating it), but so are multi-line statements in Python. But
> when you do need them, this is not something that can simply be
> provided by a third party extension. And it's not like we cannot trust
> developers to not uglify templates by wrapping at every whitespace.
> Most tags will continue to be single-line statements and will be as
> readable as ever.
>
> Admittedly, I like to wrap early, due to vertical splitting, and if
> you have some indentation and a filter with an argument, I have to
> start scrolling vertically rather quickly.
>
> Looking at the {% comment %} tag, not only do I not see now it is more
> readable than a multi-line {# #}, it also feels decidedly like a
> workaround to me, which tells me that the thing being worked around
> should be fixed.
>
> Michael
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Michael Elsdörfer]

Not to harp on about this, but I never understood not supporting multi-
line tags, in particular if it doesn't affect performance and really
is as straightforward as suggested by the OP.

Yes, they are only useful in a limited set of cases (albeit "rare" may
be overstating it), but so are multi-line statements in Python. But
when you do need them, this is not something that can simply be
provided by a third party extension. And it's not like we cannot trust
developers to not uglify templates by wrapping at every whitespace.
Most tags will continue to be single-line statements and will be as
readable as ever.

Admittedly, I like to wrap early, due to vertical splitting, and if
you have some indentation and a filter with an argument, I have to
start scrolling vertically rather quickly.

Looking at the {% comment %} tag, not only do I not see now it is more
readable than a multi-line {# #}, it also feels decidedly like a
workaround to me, which tells me that the thing being worked around
should be fixed.

Michael

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Stephen Burrows]

> Personally, I would like to be able to see a tag all at once (that is
> without scrolling), even though I might have to scroll to get to the
> start of it.  I believe this improves readability of the template. My
> specific use case is with include tags with long template paths and
> added context variables.

Most text editors let you enable line-wrapping... though this isn't as
"elegant" as multi-line tags, it would let you see everything without
scrolling.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Adrian Holovaty]

On Sat, Feb 18, 2012 at 12:04 AM, Glenn Washburn
 wrote:
> I'd like to reopen discussion on the multiline tag issue (see:
> https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.

Putting on my BDFL cap...I'd prefer not to implement multi-line tags,
purely for aesthetic reasons. It's much easier to visually parse
single-line tags, and multi-line tags look ugly.

Granted, there are some situations in which multi-line tags are an
improvement (see the example by h3 in this thread), but those are
relatively rare and don't make it worth it to me.

Adrian

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Glenn,

On 02/19/2012 07:06 PM, Glenn Washburn wrote:
> Very brief I might add.  He only alludes to one technical reason
> saying: "error trapping can occur much earlier".  I'm trying to
> understand what is meant by this as well.  I don't see how my proposed
> change affects error handling in anyway.  What problems are caused by
> my change?  I'm actually very interested in this as I'm likely going to
> be using this.

Not sure; it seems the "many discussions" of this happened before I was
around.

> I hope I'm not being too demanding by desiring a documented list of
> reasons why this is a bad idea.  I've search the groups and not found
> anything significant related to this.  Where was it discussed an are
> there logs? (was it on irc?)

I'm interested as well; I don't see obvious issues with the approach in
your patch. It may in fact be that template lexing has changed enough in
the last few years to make this simpler now than it was then.

> Is there a way we can move forward on this?

Technically speaking, the way forward would be to open a ticket and
attach a patch with tests and docs (in any case, I would do this rather
than consider reopening #3888 - it's too muddled with reference to
possible specific handling of comments). More importantly, though, given
the history here, would be to get a comment from a core developer more
familiar than I am with that history; and perhaps one with a stronger
opinion on the issue. So posting here was the right thing to do - now
the right thing is probably to wait for a bit.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9Btq4ACgkQ8W4rlRKtE2dfMACcCzIFAPiXQLbnEx5NyE4D6zDG
SyAAnjzHSKxJWLSgiiuSN1pyznjgzcuY
=cJ44
-END PGP SIGNATURE-

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Glenn Washburn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 19 Feb 2012 10:01:06 -0700
Carl Meyer  wrote:

> Here's a discussion linked from #3888 in which Malcolm lays out in
> brief why multiline tags have been rejected:
> https://groups.google.com/forum/?fromgroups#!topic/django-developers/A17TJWd3YJU

Very brief I might add.  He only alludes to one technical reason
saying: "error trapping can occur much earlier".  I'm trying to
understand what is meant by this as well.  I don't see how my proposed
change affects error handling in anyway.  What problems are caused by
my change?  I'm actually very interested in this as I'm likely going to
be using this.

I hope I'm not being too demanding by desiring a documented list of
reasons why this is a bad idea.  I've search the groups and not found
anything significant related to this.  Where was it discussed an are
there logs? (was it on irc?)

> There is indeed precedent for wontfix decisions being reversed, but
> this isn't one. The lexing bug revealed in #3888 that caused
> multiline {# #} to sorta kinda work in a broken way had its own
> ticket opened (#4164) and was fixed. In any recent Django, including
> 1.3.1 and 1.4 beta, multiline {# #} does not work at all.

Thanks Carl for pointing that out; I hadn't read that issue close
enough.  And, you're correct I am seeing that multiline {# #} are not
working in 1.3.1.

Personally, I would like to be able to see a tag all at once (that is
without scrolling), even though I might have to scroll to get to the
start of it.  I believe this improves readability of the template. My
specific use case is with include tags with long template paths and
added context variables.

Is there a way we can move forward on this?

Glenn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPQaqyAAoJEEPj94mUXoYs61oH/iGuxhABRXF9LT0qK1Kd+FHC
GH7LXijmGEsCo5KUZWmNCir3kKsi9yMJXgqt6oh7+TLj0MIpsD2PM1o9WgJwwxOz
Kbd2DYrq5jvhSPyufVaJbjgTtgLap+PtcdS5k5hJRq/gMDPbQzM8PKxbM3/Mzulo
prj5goCbVX+3NMVW7KrhnMcL3xQq8tB7cCY3azuOYCpAam8/SwFqzlx9sKdxtjbo
lGgaYPK8oi5TslQjEOvtffFXYv5yCuAAZmfFHjByr5eWYTcDJYQP7I/soQqKpkAS
fcUt74MpIODnKiiFAMroGdRfjXa7QhlxTaD6SB6kz1u7UDcM9WGFuzyajOnlzFo=
=X2ww
-END PGP SIGNATURE-

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/19/2012 10:20 AM, Torsten Bronger wrote:
> I've made the same observations as in the parallel posting: I18n
> becomes awkward with single-line tags.  We have dozens of lines like
> 
> {% blocktrans with originator=entry.originator|get_really_full_name:"mailto" 
> link=entry.get_metadata.link task_id=entry.task.id 
> process_name=entry.task.process_class|contenttype_name %}

Acknowledged. That would be a lot nicer split across multiple lines.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BM/AACgkQ8W4rlRKtE2cXkACgkRuL11edpgUB7MfRyPjuOyS7
jkAAoL4JW+CDFsryZb+UkjCizKxlMYs4
=U4+9
-END PGP SIGNATURE-

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[colinta]

Here here!  I think the django templating language is unnecessarily
restrictive in many places, but this one *really* boggles me.  Give me
back my whitespace!

(please)

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/17/2012 11:04 PM, Glenn Washburn wrote:
> I'd like to reopen discussion on the multiline tag issue (see:
> https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.

Here's a discussion linked from #3888 in which Malcolm lays out in brief
why multiline tags have been rejected:
https://groups.google.com/forum/?fromgroups#!topic/django-developers/A17TJWd3YJU

Personally I'd be -0 at worst on multiline tags, but I also don't see
any compelling use-cases. I think tags on a single line are
significantly easier to parse visually.

> Its interesting to note that
> https://code.djangoproject.com/ticket/3888, which is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.

There is indeed precedent for wontfix decisions being reversed, but this
isn't one. The lexing bug revealed in #3888 that caused multiline {# #}
to sorta kinda work in a broken way had its own ticket opened (#4164)
and was fixed. In any recent Django, including 1.3.1 and 1.4 beta,
multiline {# #} does not work at all.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BKtIACgkQ8W4rlRKtE2fnIACg0TxHHzG3rFKbRSkloeZWopmQ
3h8AoNEfygapod43tk3o6ypN2RKLAcGo
=9Xhx
-END PGP SIGNATURE-

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[h3]

I would also like to know more about the rational behind ditching the
idea of
multilinetags.

{% trans with
 varname=myobject.proprety1
 someothervar=myobject.some.other_property
 yetanothervar=myotherobject.with_a_painfully_long_method_name
 "Even with line-wrap, it's a pain to read on a single line."
%}

Forcing a Python developer to write something like this on a single
line
is borderline cruel.

Besides, it's backward compatible (I think so) and it doesn't break
syntax highlighting (in Vim at least).

+1


On Feb 18, 1:04 am, Glenn Washburn 
wrote:
> Hello django devers,
>
> I'd like to reopen discussion on the multiline tag issue 
> (see:https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.
>
> I've done rudimentary testing on a 6 character change in 1.3.1 to
> template.base.tags_re (add the re.S flag to the regex), which appears
> to solve the issue.  So I don't see all the work which was being
> referred to in mtredinnick's point two.  Perhaps the template engine
> has been rewritten since then.  The only test that fails after making
> this change (in 1.3.1) is the one that explicitly tests that tgs should
> not be multiline.
>
> Since this change appears to be so low impact and such a simple
> change.  Are there any reasons why this change shouldn't be included in
> django?  Maybe I'm missing something.
>
> Its interesting to note thathttps://code.djangoproject.com/ticket/3888, which 
> is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.
>
> -Glenn

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.