On 12/03/16 11:47, Nathan Cox wrote:
I don't understand why this conversation has had to go on for this long.

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

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

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

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

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

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

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

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

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

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

Even so, I do agree long lines reduce readability.

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

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

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

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

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

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

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

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

--
C

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

Reply via email to