Hello! GSoC 2014 is coming and I'm thinking about issue to work on.The template system is one of the components that are of special interest to me.One of the major issues is that rendering templates is slow. The problem couldbe solved by compiling template to Python bytecode, but it seems to be reallyhard to achieve, given that there was an unsuccessful attempt.
Why not switching to Jinja2? I thought that somebody else proposed this ideabut I couldn't find any discussion; so, please, point me to the discussion ifthe idea was discussed, otherwise let's discuss it!
The pros are obvious: 1) fast templates, 2) less code to maintain, 3) lot's ofcompanies use Jinja2 (because of slowness of default template system) andbuiltin support for Jinja2 would be beneficial for them (thing aboutintegrating Jinja2 with settings like TEMPLATE_DEBUG).Now the cons. First of all, one of the design decision is that Django has nodependencies. We can overwhelm it by "static linking" -- I mean copying Jinja2code into Django. At the first glance, it may look like a horrible idea, butthink about it in a different way. If we don't switch to Jinja2, we have tomaintain entire template system and fix every bug as well as implement newfeatures. If we switch, Jinja2 developers can do this job for us. We only needto forward tickets to Jinja2 developers and update the static linkage.
The second big problem is that switching is a big change and backwardcompatibility matters. We will need to support both the deprecated Djangotemplate system and the new one. However, it doesn't mean double work -- wedon't need to implement new features for the deprecated system, only bug fixeswill be required. Also note, that a lot of companies uses Jinja2 and switchingfrom third-package Jinja2 to Jinja2-builtin-Django isn't an enormous change atall.
I'd like to hear your opinion. Feel free to comment!
BTW, I'd like to have an internship in the late summer. It's impossible towork at GSoC and have an internship at the same time, but I really want to doboth, so I need to start GSoC as early as possible, at 21 April or evenearlier. Is it possible?
--To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq8489OcnOg_KE6PsAghqF6smSY8hRW3gKsmoGT%2Bec1kBMiw%40mail.gmail.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/CAG_XiSAXUZDMJ04k88nh%2BZW9J2khCGrpQTe9WiK5U_%3Df4Ad%2Bhw%40mail.gmail.com.
It's a problem that we are unable to do things
that would otherwise be no-brainers (e.g. rendering form widgets using
templates rather than by concatenating strings of HTML in Python code)
because our default templating language is too slow.
It's a problem that we are unable to do things
that would otherwise be no-brainers (e.g. rendering form widgets using
templates rather than by concatenating strings of HTML in Python code)
because our default templating language is too slow.The deliberate hobbling aspect also makes situations like this that should be no-brainers into painful slogs. Form widgets are a great example beyond this, too, because customizing HTML for particular form elements (e.g. adding size="30" to one input field) is an absolute pain. The blessed way involves overwriting the field, which requires copying every single relevant attribute of the model (and then double-maintaining changes).The Flask extension's mechanism is {{ field(size=30) }}. Done.
On Tue, Feb 11, 2014 at 9:31 AM, Luke Sneeringer <lu...@sneeringer.com> wrote:
It's a problem that we are unable to do things
that would otherwise be no-brainers (e.g. rendering form widgets using
templates rather than by concatenating strings of HTML in Python code)
because our default templating language is too slow.The deliberate hobbling aspect also makes situations like this that should be no-brainers into painful slogs. Form widgets are a great example beyond this, too, because customizing HTML for particular form elements (e.g. adding size="30" to one input field) is an absolute pain. The blessed way involves overwriting the field, which requires copying every single relevant attribute of the model (and then double-maintaining changes).The Flask extension's mechanism is {{ field(size=30) }}. Done.Please don't fall into the trap of assuming I'm mentally impaired in some way.
I'm also aware of the ways it can be abused. I'd be able to mount a reasonable argument that {{ field(size=30) }} is a problem, not a feature (whats the magical significance of 30? What happens if you make a site-wide decision to extend all size=30 fields to size=40? etc. And, to be clear, I'm not interested in having *this* specific argument in long form. Just be aware that I'd make it, and that it's the argument that underpins the original design decisions of Django's template language).
I'm also aware that this is *my* analysis, and that others will come to a different conclusion, based on their own values, priorities, experiences, and engineering taste.This doesn't make *either* analysis wrong. It means different people value different things.
[1] https://github.com/mitsuhiko/jinja2/graphs/contributors
--
Aymeric.
--
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/70B2B842-9977-4F60-B743-4662019DE56A%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.
On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela <chris....@gmail.com> wrote:Hello! GSoC 2014 is coming and I'm thinking about issue to work on.The template system is one of the components that are of special interest to me.One of the major issues is that rendering templates is slow. The problem couldbe solved by compiling template to Python bytecode, but it seems to be reallyhard to achieve, given that there was an unsuccessful attempt.
This should set off a red flag for you. The GSoC project to byte code compile Django's templates was implemented by Armin, the same person who wrote Jinja2 - and yet the project didn't fully succeed. It's worth investigating *why* this idea failed, because it flags one of the reasons why "just adopt Jinja2" may not be a viable options.
The pros are obvious: 1) fast templates, 2) less code to maintain, 3) lot's ofcompanies use Jinja2 (because of slowness of default template system) andbuiltin support for Jinja2 would be beneficial for them (thing aboutintegrating Jinja2 with settings like TEMPLATE_DEBUG).Now the cons. First of all, one of the design decision is that Django has nodependencies. We can overwhelm it by "static linking" -- I mean copying Jinja2code into Django. At the first glance, it may look like a horrible idea, butthink about it in a different way. If we don't switch to Jinja2, we have tomaintain entire template system and fix every bug as well as implement newfeatures. If we switch, Jinja2 developers can do this job for us. We only needto forward tickets to Jinja2 developers and update the static linkage.
We're unlikely to vendor a copy of Jinja2. If we went down this road, we'd be much more likely to look at using dependencies defined in setup.py.
BTW, I'd like to have an internship in the late summer. It's impossible towork at GSoC and have an internship at the same time, but I really want to doboth, so I need to start GSoC as early as possible, at 21 April or evenearlier. Is it possible?
It depends on exactly how long the overlapping period is. If it's a matter of a week or two, and we have a good proposal from a student, I suspect we'd be happy to internally shift the dates for the GSoC by a fortnight to accommodate them. In the past, we've accommodated students who have a 2 week exam period in the middle of the GSoC; I don't see why we wouldn't extend the same courtesy to an overlap at the end of the GSoC. However, the longer the overlap, the less likely we are to be accommodating.
Although Jinja2 and Django template share a common base syntax, Jinja2 includes a bunch of features that I'm not wild about. Django's templates are *deliberately* hobbled to prevent the injection of business logic into templates. Jinja2 template allow for function calls, array subscripting, and all sorts of other programming language structures. I'm not saying these things are inherently bad; I'm saying there's a reason why Django hasn't included them, and I'm not wild about the idea of switching to a default template language that allows them.
Russell makes the very good point that Jinja2 isn't just a faster version of the Django template engine - it's philosophically at odds with the original design and intent of the Django template engine.
Personally, I prefer Jinja2's approach and would love to see it become the standard. (The benefits of improved performance, and of moving templates out of core, are nice as well.) But before there's a switch we would need to discuss this philosophical difference and come to a consensus that the Jinja2 approach is, at least, acceptable.
In the absence of a plan to eventually switch to Jinja2, I'm not sure a re-architecting (option 2) is a great use of time. Why? Because in my experience the existing solutions work fine. I'm using Jinja2 and the django-jinja adapter in my projects and everything pretty much just works.
I have only one significant concern. Jinja2 is still a one-man-project [1] and
that man has taken a public stance on Python 3 that is at odds with Django's.
It's often misinterpreted as "Python 3 sucks" after a cursory reading.
What did Armin said about Python 3 exactly?
--
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/CANE-7mU31zMRkVrJAZY_tde-xdiU63p2s38pB2vVPpeDpPBkxQ%40mail.gmail.com.
There are a few problems with Christian's assumptions:
* Not everyone uses a JS Framework. Personally, we use a lot of static pages, and when we do want to do some fancy stuff, we use pjax to replace content on the page, but in the backend this is still done by rendering a full template through a Django view.
* The templating language is also used for small stuff, and the switch to Jinja would enable using the templating language for even more stuff. The biggest issue that comes to mind are template-based widgets.
Personally, I'm in favor of switching to Jinja. The speed bonus and the ability to call functions with arguments are great features for me.
One downside I can think of is that Jinja does not escape variables by default, which might become a XSS security 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/CAG_XiSBmOU%3D4orZnW13bw-ZLT_O416unynhtnQ9%3DhgPtL9Bbtw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1GCQG1q5W_BmU%3DNTA0zmydnTuhVH%3DFrtdDR-kXVSLTZ8Q%40mail.gmail.com.
2014-02-11 13:42 GMT+01:00 Christopher Medrela <chris....@gmail.com>:What did Armin said about Python 3 exactly?He wrote an extensive argumentation about "why Python 2 [is] the betterlanguage for dealing with text and bytes" [1] as well as a number of tweetsand a few other blog posts along the same lines.While his arguments are technically correct, I disagree with his conclusionsbecause he's speaking with the point of view of an expert maintaininglibraries at the boundary between unicode and bytes (like werkzeug). However,most Python users aren't experts and aren't maintaining such libraries. In myexperience working with Python programmers ranging from intern to veteran, theunicode model of Python 3 is a strict improvement over Python 2 in terms ofpitfalls hit in day-to-day programming. YMMV.--Aymeric.
My last post was pretty long and the most important questions and statementshave left unanswered, so I will repeat them.What I'm proposing now is more conservative proposal. Firstly, Django willsupport Jinja2 out-of-the-box, but DTL will remain the "blessed" option.Secondly, Django will allow to mix DTL and Jinja2 templates (so you caninclude/inherit DTL template from Jinja2 one and vice versa).After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting Djangobuiltin templates in Jinja2 or/and 5) moving rendering form widgets fromPython code to Jinja2 templates.After that all, we could start again the war DTL vs Jinja2, but please focuson the new proposal now.Questions are:1) What do you think about the new proposal? Would it be useful?2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are weready for this?
On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:2014-02-11 13:42 GMT+01:00 Christopher Medrela <chris....@gmail.com>:What did Armin said about Python 3 exactly?He wrote an extensive argumentation about "why Python 2 [is] the betterlanguage for dealing with text and bytes" [1] as well as a number of tweetsand a few other blog posts along the same lines.While his arguments are technically correct, I disagree with his conclusionsbecause he's speaking with the point of view of an expert maintaininglibraries at the boundary between unicode and bytes (like werkzeug). However,most Python users aren't experts and aren't maintaining such libraries. In myexperience working with Python programmers ranging from intern to veteran, theunicode model of Python 3 is a strict improvement over Python 2 in terms ofpitfalls hit in day-to-day programming. YMMV.--Aymeric.OK, so Armin finds Python 2 better than Python 3. But why is it at odds withDjango? He didn't say that he is not going to support Python 3. So where isthe risk that concerns you?
--
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/79dbbf71-6b70-48d1-8510-cef471812677%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On 15 Feb 2014 18:13, "Donald Stufft" <don...@stufft.io> wrote:
>
>
> On Feb 15, 2014, at 11:43 AM, Christopher Medrela <chris....@gmail.com> wrote:
>
>> My last post was pretty long and the most important questions and statements
>> have left unanswered, so I will repeat them.
>>
>> What I'm proposing now is more conservative proposal. Firstly, Django will
>> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
>> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
>> include/inherit DTL template from Jinja2 one and vice versa).
>>
>> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting Django
>> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
>> Python code to Jinja2 templates.
>>
>> After that all, we could start again the war DTL vs Jinja2, but please focus
>> on the new proposal now.
>>
>> Questions are:
>>
>> 1) What do you think about the new proposal? Would it be useful?
>>
>> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
>>
>> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>> ready for this?
>
>
> If we have Jinja2 I don’t see any reason to keep the DTL as the blessed option.
Exactly
My last post was pretty long and the most important questions and statementshave left unanswered, so I will repeat them.What I'm proposing now is more conservative proposal. Firstly, Django willsupport Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
Secondly, Django will allow to mix DTL and Jinja2 templates (so you caninclude/inherit DTL template from Jinja2 one and vice versa).
After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting Djangobuiltin templates in Jinja2 or/and 5) moving rendering form widgets fromPython code to Jinja2 templates.After that all, we could start again the war DTL vs Jinja2, but please focuson the new proposal now.Questions are:1) What do you think about the new proposal? Would it be useful?
2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are weready for this?
On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:2014-02-11 13:42 GMT+01:00 Christopher Medrela <chris....@gmail.com>:What did Armin said about Python 3 exactly?He wrote an extensive argumentation about "why Python 2 [is] the betterlanguage for dealing with text and bytes" [1] as well as a number of tweetsand a few other blog posts along the same lines.While his arguments are technically correct, I disagree with his conclusionsbecause he's speaking with the point of view of an expert maintaininglibraries at the boundary between unicode and bytes (like werkzeug). However,most Python users aren't experts and aren't maintaining such libraries. In myexperience working with Python programmers ranging from intern to veteran, theunicode model of Python 3 is a strict improvement over Python 2 in terms ofpitfalls hit in day-to-day programming. YMMV.--Aymeric.OK, so Armin finds Python 2 better than Python 3. But why is it at odds withDjango? He didn't say that he is not going to support Python 3. So where isthe risk that concerns you?
On Feb 15, 2014, at 11:43 AM, Christopher Medrela <chris....@gmail.com> wrote:My last post was pretty long and the most important questions and statementshave left unanswered, so I will repeat them.What I'm proposing now is more conservative proposal. Firstly, Django willsupport Jinja2 out-of-the-box, but DTL will remain the "blessed" option.Secondly, Django will allow to mix DTL and Jinja2 templates (so you caninclude/inherit DTL template from Jinja2 one and vice versa).After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting Djangobuiltin templates in Jinja2 or/and 5) moving rendering form widgets fromPython code to Jinja2 templates.After that all, we could start again the war DTL vs Jinja2, but please focuson the new proposal now.Questions are:1) What do you think about the new proposal? Would it be useful?2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are weready for this?If we have Jinja2 I don’t see any reason to keep the DTL as the blessed option.