Revisiting multiline tags

2,793 views
Skip to first unread message

Glenn Washburn

unread,
Feb 18, 2012, 1:04:33 AM2/18/12
to django-d...@googlegroups.com
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

h3

unread,
Feb 19, 2012, 12:18:35 AM2/19/12
to Django developers
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 <developm...@efficientek.com>
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

Carl Meyer

unread,
Feb 19, 2012, 12:01:06 PM2/19/12
to django-d...@googlegroups.com
-----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-----

colinta

unread,
Feb 19, 2012, 9:30:21 AM2/19/12
to Django developers
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)

Torsten Bronger

unread,
Feb 19, 2012, 12:20:24 PM2/19/12
to django-d...@googlegroups.com
Hall�chen!

Carl Meyer writes:

> 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

Thank you! Still, does anybody have a link where the technical
problems (in constrast to the aesthetical ones) are discussed?

> 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.

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 %}

Another use case, however less frequent in our code:

href="{% url samples.views.sample.export sample_name=sample.sample.name %}?next={{ sample.sample.get_absolute_url|urlquote_plus }}"

Tsch�,
Torsten.

--
Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com

Carl Meyer

unread,
Feb 19, 2012, 12:40:00 PM2/19/12
to django-d...@googlegroups.com
-----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-----

Glenn Washburn

unread,
Feb 19, 2012, 9:06:42 PM2/19/12
to django-d...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 19 Feb 2012 10:01:06 -0700
Carl Meyer <ca...@oddbird.net> 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-----

Carl Meyer

unread,
Feb 19, 2012, 9:57:50 PM2/19/12
to django-d...@googlegroups.com
-----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-----

Adrian Holovaty

unread,
Feb 19, 2012, 11:33:15 PM2/19/12
to django-d...@googlegroups.com
On Sat, Feb 18, 2012 at 12:04 AM, Glenn Washburn
<devel...@efficientek.com> 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

Stephen Burrows

unread,
Feb 20, 2012, 12:48:49 AM2/20/12
to Django developers
> 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.

Michael Elsdörfer

unread,
Feb 21, 2012, 9:34:54 AM2/21/12
to Django developers
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

Andre Terra

unread,
Feb 23, 2012, 8:44:49 AM2/23/12
to django-d...@googlegroups.com
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



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


colinta

unread,
Feb 23, 2012, 11:18:12 PM2/23/12
to Django developers
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.

Russell Keith-Magee

unread,
Feb 24, 2012, 1:29:31 AM2/24/12
to django-d...@googlegroups.com

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 %-)

Stephan Jaensch

unread,
Feb 24, 2012, 4:01:23 AM2/24/12
to django-d...@googlegroups.com
>> 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

Bradley Ayers

unread,
Feb 24, 2012, 4:19:54 AM2/24/12
to django-d...@googlegroups.com

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

Shawn Milochik

unread,
Feb 24, 2012, 4:23:37 AM2/24/12
to django-d...@googlegroups.com
On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers <bradle...@gmail.com> 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

Chris Northwood

unread,
Feb 24, 2012, 4:29:51 AM2/24/12
to django-d...@googlegroups.com
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...

Luke Granger-Brown

unread,
Feb 24, 2012, 5:20:43 AM2/24/12
to django-d...@googlegroups.com

+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.

Jonas H.

unread,
Feb 24, 2012, 5:29:50 AM2/24/12
to django-d...@googlegroups.com
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? :-)

Ivan Kharlamov

unread,
Feb 24, 2012, 5:29:52 AM2/24/12
to django-d...@googlegroups.com

+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).

Jonathan French

unread,
Feb 24, 2012, 7:02:41 AM2/24/12
to django-d...@googlegroups.com
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

Daniel Moisset

unread,
Feb 24, 2012, 10:01:32 AM2/24/12
to django-d...@googlegroups.com
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.

Alex Gaynor

unread,
Feb 24, 2012, 10:12:38 AM2/24/12
to django-d...@googlegroups.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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.


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

Daniel Moisset

unread,
Feb 24, 2012, 10:15:39 AM2/24/12
to django-d...@googlegroups.com
On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor <alex....@gmail.com> 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

Carl Meyer

unread,
Feb 24, 2012, 10:27:06 AM2/24/12
to django-d...@googlegroups.com
-----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-----

Paul Egges

unread,
Feb 24, 2012, 10:44:32 AM2/24/12
to django-d...@googlegroups.com
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

Tom Evans

unread,
Feb 24, 2012, 11:06:39 AM2/24/12
to django-d...@googlegroups.com
On Fri, Feb 24, 2012 at 3:12 PM, Alex Gaynor <alex....@gmail.com> 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

Daniel Sokolowski

unread,
Feb 24, 2012, 11:14:47 AM2/24/12
to django-d...@googlegroups.com
+1 and reason as previously stated: it makes sense to brake down very long tags for readability purposes.
Sent: Friday, February 24, 2012 10:12 AM
Subject: Re: Revisiting multiline tags
 


On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset <dmoi...@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-d...@googlegroups.com.
To unsubscribe from this group, send email to mailto:django-developers%2Bunsu...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Łukasz Rekucki

unread,
Feb 24, 2012, 11:29:33 AM2/24/12
to django-d...@googlegroups.com
With all the voting and aesthetic discussion, maybe let's get back to
technical details:

On 24 February 2012 05:18, colinta <col...@gmail.com> 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

Łukasz Rekucki

unread,
Feb 24, 2012, 11:31:40 AM2/24/12
to django-d...@googlegroups.com
On 24 February 2012 17:29, Łukasz Rekucki <lrek...@gmail.com> wrote:
> With all the voting and aesthetic discussion, maybe let's get back to
> technical details:
>
> On 24 February 2012 05:18, colinta <col...@gmail.com> 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

h3

unread,
Feb 24, 2012, 12:06:06 PM2/24/12
to Django developers
> 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 <dmois...@machinalis.com> wrote:

Alex Gaynor

unread,
Feb 24, 2012, 12:16:28 PM2/24/12
to django-d...@googlegroups.com
On Fri, Feb 24, 2012 at 12:06 PM, h3 <hain...@gmail.com> 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 <dmois...@machinalis.com> wrote:
> On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor <alex.gay...@gmail.com> 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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Jonathan French

unread,
Feb 24, 2012, 2:13:52 PM2/24/12
to django-d...@googlegroups.com
On 24 February 2012 17:16, Alex Gaynor <alex....@gmail.com> wrote:


On Fri, Feb 24, 2012 at 12:06 PM, h3 <hain...@gmail.com> 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?

Michael Elsdörfer

unread,
Feb 24, 2012, 4:04:43 PM2/24/12
to Django developers
> 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

Yo-Yo Ma

unread,
Feb 24, 2012, 11:55:43 PM2/24/12
to Django developers
I'm -1 on this for s specific reason; If you need multiple lines for a
tag, you're doing it wrong.

>>> import this

Stan

unread,
Feb 25, 2012, 4:31:01 AM2/25/12
to Django developers
*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 <dmois...@machinalis.com> wrote:

Ned Batchelder

unread,
Feb 25, 2012, 8:48:42 PM2/25/12
to django-d...@googlegroups.com, Yo-Yo Ma
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.

Joe & Anne Tennies

unread,
Feb 25, 2012, 11:55:02 PM2/25/12
to django-d...@googlegroups.com
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.

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




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

Yo-Yo Ma

unread,
Feb 26, 2012, 12:12:45 AM2/26/12
to Django developers
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.

Łukasz Rekucki

unread,
Feb 26, 2012, 4:38:33 AM2/26/12
to django-d...@googlegroups.com
On 26 February 2012 05:55, Joe & Anne Tennies <ten...@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.


--
Łukasz Rekucki

Donald Stufft

unread,
Feb 26, 2012, 4:42:57 AM2/26/12
to django-d...@googlegroups.com
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

Łukasz Rekucki

unread,
Feb 26, 2012, 4:54:52 AM2/26/12
to django-d...@googlegroups.com
On 26 February 2012 06:12, Yo-Yo Ma <baxters...@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.

--
Łukasz Rekucki

Donald Stufft

unread,
Feb 26, 2012, 4:57:17 AM2/26/12
to django-d...@googlegroups.com
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

Mikhail Korobov

unread,
Feb 26, 2012, 5:07:55 AM2/26/12
to django-d...@googlegroups.com
воскресенье, 26 февраля 2012 г. 15:38:33 UTC+6 пользователь Łukasz Rekucki написал:
On 26 February 2012 05:55, Joe & Anne Tennies <ten...@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.

Joe & Anne Tennies

unread,
Feb 26, 2012, 11:13:30 AM2/26/12
to django-d...@googlegroups.com
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 <lrek...@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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.




--

Ned Batchelder

unread,
Feb 27, 2012, 9:37:56 AM2/27/12
to django-d...@googlegroups.com, Yo-Yo Ma
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.

Nick Phillips

unread,
Feb 28, 2012, 4:05:19 PM2/28/12
to django-d...@googlegroups.com
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.p...@otago.ac.nz
# these statements are my own, not those of the University of Otago

Anssi Kääriäinen

unread,
Feb 28, 2012, 4:37:37 PM2/28/12
to Django developers
On Feb 28, 11:05 pm, Nick Phillips <nick.phill...@otago.ac.nz> 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

colinta

unread,
Mar 15, 2012, 1:11:18 PM3/15/12
to Django developers
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.

Daniel Ellis

unread,
Jul 15, 2013, 2:34:27 PM7/15/13
to django-d...@googlegroups.com, Yo-Yo Ma
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.

Jacob Kaplan-Moss

unread,
Jul 15, 2013, 5:41:25 PM7/15/13
to django-developers
On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis <elli...@gmail.com> 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

Daniel Ellis

unread,
Jul 16, 2013, 9:41:31 AM7/16/13
to django-d...@googlegroups.com
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.



--
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.

Russell Keith-Magee

unread,
Jul 16, 2013, 8:48:38 PM7/16/13
to django-d...@googlegroups.com
On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis <elli...@gmail.com> 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 %-)

Wim Feijen

unread,
Aug 18, 2013, 3:57:36 AM8/18/13
to django-d...@googlegroups.com
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

Russell Keith-Magee

unread,
Aug 18, 2013, 7:59:13 PM8/18/13
to Django Developers
On Sun, Aug 18, 2013 at 3:57 PM, Wim Feijen <w...@go2people.nl> 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 %-)

Adam Serafini

unread,
Mar 5, 2014, 7:07:20 AM3/5/14
to django-d...@googlegroups.com
+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!)

Daniel Ellis

unread,
Mar 5, 2014, 8:23:42 AM3/5/14
to django-d...@googlegroups.com
+1 - I've had the same issue with sorl thumbnail.


--
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.

Andre Terra

unread,
Mar 6, 2014, 3:28:59 PM3/6/14
to django-d...@googlegroups.com
+1, for one simple reason: practicality beats purity.


--
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-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.

Curtis Maloney

unread,
Mar 9, 2014, 5:47:25 AM3/9/14
to django-d...@googlegroups.com
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


Curtis Maloney

unread,
Mar 9, 2014, 11:44:03 PM3/9/14
to django-d...@googlegroups.com
For those interested, I've now got my branch working, and only failing tests related to ensuring no newlines appear inside tags.


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

Eric Rouleau

unread,
Mar 11, 2014, 2:42:13 AM3/11/14
to django-d...@googlegroups.com
+1 for me too

Carl

unread,
Apr 3, 2014, 9:50:58 AM4/3/14
to django-d...@googlegroups.com
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

Daniele Procida

unread,
Apr 3, 2014, 10:13:33 AM4/3/14
to django-d...@googlegroups.com
On Thu, Apr 3, 2014, Carl <ca...@supervacuo.com> 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

dude

unread,
Apr 3, 2014, 10:17:38 AM4/3/14
to django-d...@googlegroups.com
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 <dan...@vurt.org> написал(а):
> --
> 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-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/20140403141333.1946415207%40smtpauth.cf.ac.uk.
> For more options, visit https://groups.google.com/d/optout.

Daniel Ellis

unread,
Apr 3, 2014, 10:29:01 AM4/3/14
to django-d...@googlegroups.com
Hmm, that does seem like a great idea!

dude

unread,
Apr 3, 2014, 10:52:24 AM4/3/14
to django-d...@googlegroups.com
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 <elli...@gmail.com> написал(а):

Curtis Maloney

unread,
Apr 3, 2014, 8:29:19 PM4/3/14
to django-d...@googlegroups.com
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

Curtis Maloney

unread,
Apr 11, 2014, 11:51:12 PM4/11/14
to django-d...@googlegroups.com
Would it help if I said please?

Loic Bistuer

unread,
Apr 15, 2014, 12:05:50 AM4/15/14
to django-d...@googlegroups.com
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

Rafał Pitoń

unread,
Apr 15, 2014, 12:28:53 PM4/15/14
to django-d...@googlegroups.com
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.

Adrian Holovaty

unread,
Apr 15, 2014, 11:36:00 PM4/15/14
to django-d...@googlegroups.com
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


--
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-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.

Russell Keith-Magee

unread,
Apr 15, 2014, 11:46:18 PM4/15/14
to Django Developers
On Wed, Apr 16, 2014 at 11:36 AM, Adrian Holovaty <adr...@holovaty.com> 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 %-)

Curtis Maloney

unread,
Apr 15, 2014, 11:48:22 PM4/15/14
to django-d...@googlegroups.com
I'm happy to coalesce this into a DEP... is there a format template I can follow?


--
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-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.

Loic Bistuer

unread,
Apr 16, 2014, 12:15:00 AM4/16/14
to django-d...@googlegroups.com
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 

Curtis Maloney

unread,
Apr 16, 2014, 12:17:58 AM4/16/14
to django-d...@googlegroups.com


--
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-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.

Loic Bistuer

unread,
Apr 16, 2014, 4:31:46 AM4/16/14
to django-d...@googlegroups.com
Curtis' branch is now a PR:


Feedback is welcome.

-- 
Loic

Adam Serafini

unread,
Apr 16, 2014, 5:20:08 AM4/16/14
to django-d...@googlegroups.com
Curtis, I added a thumbnail example to the DEP (pull request in github).


--
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.

imfletcher

unread,
Apr 16, 2014, 11:46:20 AM4/16/14
to django-d...@googlegroups.com
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.

Andre Terra

unread,
Apr 16, 2014, 5:43:45 PM4/16/14
to django-d...@googlegroups.com
On Wed, Apr 16, 2014 at 12:46 PM, imfletcher <jbr...@gmail.com> 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


Josh Smeaton

unread,
Apr 16, 2014, 6:47:10 PM4/16/14
to django-d...@googlegroups.com
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

Loic Bistuer

unread,
Apr 16, 2014, 10:14:25 PM4/16/14
to django-d...@googlegroups.com
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

ted

unread,
Apr 29, 2014, 10:02:26 PM4/29/14
to django-d...@googlegroups.com
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

Florian Apolloner

unread,
Apr 29, 2014, 10:24:12 PM4/29/14
to django-d...@googlegroups.com
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

ted

unread,
May 10, 2014, 1:01:15 PM5/10/14
to django-d...@googlegroups.com
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

Martijn van Oosterhout

unread,
Dec 22, 2014, 6:48:16 AM12/22/14
to django-d...@googlegroups.com
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 {{ '<a href=link>' }}here{{ '</a>' }}{% endblocktrans %}

using the same hidden variables as above. That would make it much easier to separate the text from the layout. Perhaps even {{ '<a href=link>' 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?

Flimm

unread,
Dec 30, 2015, 12:05:29 PM12/30/15
to Django developers (Contributions to Django itself)
+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

Nathan Cox

unread,
Mar 11, 2016, 7:54:46 PM3/11/16
to Django developers (Contributions to Django itself)
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.

Josh Smeaton

unread,
Mar 11, 2016, 9:10:44 PM3/11/16
to Django developers (Contributions to Django itself)
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?

Curtis Maloney

unread,
Mar 11, 2016, 11:31:48 PM3/11/16
to django-d...@googlegroups.com


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

Martijn van Oosterhout

unread,
Mar 13, 2016, 1:27:04 AM3/13/16
to django-d...@googlegroups.com

On 12 March 2016 at 05:31, Curtis Maloney <cur...@tinbrain.net> 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,
--

Collin Anderson

unread,
Mar 16, 2016, 10:58:00 PM3/16/16
to django-d...@googlegroups.com

--
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-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages