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
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-----
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
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-----
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-----
Putting on my BDFL cap...I'd prefer not to implement multi-line tags,
purely for aesthetic reasons. It's much easier to visually parse
single-line tags, and multi-line tags look ugly.
Granted, there are some situations in which multi-line tags are an
improvement (see the example by h3 in this thread), but those are
relatively rare and don't make it worth it to me.
Adrian
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-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.
I can certainly appreciate the reasons why those asking for this change would like to see the change made, but please don't attempt to characterize this thread as clear and overwhelming support for change.
This thread contains 6 people expressing support for this change, and 2 against (a BDFL, a core developer) -- and you can add me to the -0 list. There are over 6000 subscribers to django-developers. I put it to you that the vast majority of people haven't expressed an opinion -- and many of those haven't expressed an opinion because they're happy with (or indifferent to) the status quo, and a BDFL has already indicated that the status quo is his preferred option.
This is also the first time the issue has been raised on django-dev for some time -- I can't even remember the last time the subject was raised. If this is such a demand of the populous, why isn't it a regular topic of discussion on django-dev?
Finally, your arguments in favor of making this change are almost entirely technical -- easy fix, backwards compatible, no performance hit. However, you've missed the non-technical aspects -- that introducing multiline tags would fundamentally change the flavor of Django templates. Part of the job of the BDFLs is to make aesthetic choices. As indicated by Adrian in his response, this is largely an aesthetic decision on his part. Aesthetic choices aren't always popular, and almost by definition won't make everyone happy, but they are an essential part of what gives Django it's distinctive flavor.
Yours,
Russ Magee %-)
You asked for it, so here is my +1.
> This is also the first time the issue has been raised on django-dev for some time -- I can't even remember the last time the subject was raised. If this is such a demand of the populous, why isn't it a regular topic of discussion on django-dev?
Because the Django community is extremely nice and well-behaved...? :) I too was unhappy with the decision, but didn't feel it was important enough to post in this thread. That doesn't mean I wouldn't appreciate multiline tags.
> Finally, your arguments in favor of making this change are almost entirely technical -- easy fix, backwards compatible, no performance hit. However, you've missed the non-technical aspects -- that introducing multiline tags would fundamentally change the flavor of Django templates. Part of the job of the BDFLs is to make aesthetic choices. As indicated by Adrian in his response, this is largely an aesthetic decision on his part. Aesthetic choices aren't always popular, and almost by definition won't make everyone happy, but they are an essential part of what gives Django it's distinctive flavor.
Well, and you are really making the non-technical argument for the supporters, aren't you? If multiline tags would fundamentally change the flavor of Django templates, it would mean that suddenly people everywhere would start using them, massively. This would mean there is overwhelming demand for them. But if people do only use them in the cases where it's appropriate (e.g. the dreaded trans tag, multi-line comments and so forth) then it doesn't change much of anything and just makes templates more readable.
I understand this is an aesthetic decision. I just wish to point out that you can't make the argument that nobody wants it and that it would also have a big impact.
Cheers,
Stephan
In the interest of making the wider community opinion heard, I too am +1 on this, my feeling is exactly the same as Stephen.
+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
+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.
+1 from me too.
Maybe someone could invent an official feature voting tool? :-)
+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).
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 django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
It's useful because it helps some templaets in some cases be more readable
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-----
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
On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch <s...@sjaensch.org> wrote:And mine; even if I might have needed multiline tags once or twice in
>> 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.
>
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.
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
I meant EOL of course.
--
Łukasz Rekucki
> 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:
> 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.
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.
--Ned.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-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.
> 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
--Łukasz Rekucki
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
--Ł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.
--
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.
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.
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
Is it considered gauche to revive old topics such as this?
{% if reactor.safe_to_release_deadly_radiation and reactor.definitely_wont_kill %}{{ release_form }}{% else %}{{ make_safe_to_release_form }}{% endif %}
{% if reactor.safe_to_release_deadly_radiation and reactor.definitely_wont_kill or 1 %}{{ release_form }}{% else %}{{ make_safe_to_release_form }}{% endif %}
--
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.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
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.
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?
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1d8b7534-07b8-40f4-9f8d-ebd642a8217d%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJGew6nqpCZ7eRLGRb4hCjP6DBWHrt9etBGWsewMDcoRJ%3DM2eA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKBiv3yAJVsm8G4k3xqcGNsvYRyRquCs-8B_pCbTjbZZSkYdKA%40mail.gmail.com.
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
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.
--
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/420eb9bd-f9fd-47df-af26-425697577bd9%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq848yJwfrGtvY-Uta3e-1ooQb5J56SZXjru_yeOC%3DjzzLBw%40mail.gmail.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.
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?
--
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/07a50d8f-4b4b-4917-aa31-662c0376943d%40googlegroups.com.
--You received this message because you are subscribed to a topic in the Google Groups "Django developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/76cf2490-a88e-477f-948d-f15b4018c586%40googlegroups.com.
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.
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.
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
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.
--
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.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADWG95v7eMb8u85PyS3MsigXMVoKs3a_H9zx8aGJBsetBaWyLQ%40mail.gmail.com.