I'm really astonished how much feedback I got! On Sunday, February 9, 2014 1:11:19 AM UTC+1, Russell Keith-Magee wrote: > > On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela <[email protected]> > 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 >> could >> be solved by compiling template to Python bytecode, but it seems to be >> really >> hard 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. >
Armin said in his proposal [1] that he wanted to "rewrite Jinja2 code generation to better support alternative Python implementations like PyPy" and I guess that was the reason why he didn't adopt "just switch to Jinja2" approach. Also note, that his proposal was about writing a backend for both Jinja2 and DTL. That was really ambitious so there is no risk like "he failed writing backend for two template engines so switching to Jinja2 will probably also fail". [1] https://groups.google.com/forum/#!searchin/django-developers/gsoc$20compilation/django-developers/amUQgS4QvOM The pros are obvious: 1) fast templates, 2) less code to maintain, 3) lot's >> of >> companies use Jinja2 (because of slowness of default template system) and >> builtin support for Jinja2 would be beneficial for them (thing about >> integrating Jinja2 with settings like TEMPLATE_DEBUG). >> >> Now the cons. First of all, one of the design decision is that Django has >> no >> dependencies. We can overwhelm it by "static linking" -- I mean copying >> Jinja2 >> code into Django. At the first glance, it may look like a horrible idea, >> but >> think about it in a different way. If we don't switch to Jinja2, we have >> to >> maintain entire template system and fix every bug as well as implement new >> features. If we switch, Jinja2 developers can do this job for us. We only >> need >> to 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. > So we need to discuss introducing dependencies. Django design decision were made long time ago when python packaging mechanism was bad, so avoiding dependencies was obvious, but this argument is no longer valid. So are we ready to introduce Jinja2 dependency in Django 1.8? This is important question because introducing dependencies is necessary condition for switching/supporting Jinja2 and if we don't reach a consensus, it'll be better to stop discussion and focus on more productive activities (like considering other GSoC ideas). BTW, I'd like to have an internship in the late summer. It's impossible to >> work at GSoC and have an internship at the same time, but I really want >> to do >> both, so I need to start GSoC as early as possible, at 21 April or even >> earlier. 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. > Before approx. April, I can't say how much do I need to shift dates. I'm going to apply for these internships which won't collide with GSoC and more we shift the dates, more internships are available for me. 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. > But on the other side DTL encourage you to put too much in views. What you can't do in a template, you can do in a view and pass it to the template via context. And this isn't good too. If we switched to Jinja2 and made it the "blessed" option, we could document only a subset of Jinja2 features, so newbies (who read Django documentation and didn't read Jinja2 docs -- that is the majority of newbies) won't inject business logic into templates. And at the same time, experienced users can read Jinja2 docs and learn all features and they won't be limited by weaknesses of DTL. That's the best of two worlds. On Sunday, February 9, 2014 8:45:06 PM UTC+1, Kevin Christopher Henry wrote: > > 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. > OK, so the list of Django principles that Jinja2 doesn't meet is: 1) Separate logic from presentation 2) Don’t invent a programming language 3) Safety and security IMO DTL meets these principles at great cost. DTL is a proof that you cannot create a language that prevents users from including business logic in template while keeping the language powerful as well as comfortable and not forcing people to write some parts of templates outside templates. I see that we should prevent newbies, but it comes at huge cost. Maybe we should change these design principles and sacrifice preventing new users for convenience of experienced users? 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. If we support both DTL and Jinja2 and allow to mix templates (so you can include DTL template from Jinja2 one and vice versa), it can be a great use of time, even if DTL will stay as the "blessed" option: 1) Django users, who would like to switch from DTL to Jinja2, could do it incrementally, instead of "rewrite everything at once" option, which is just impossible for large projects. 2) The same argument is true for builtin templates. We could rewrite some builtin DTL templates especially these slow ones. We could move rendering form widgets from Python code to templates! And because DTL stays as the blessed option, you don't have the problem of template system's principles. This is what I'm proposing now: 1) supporting Jinja2 out-of-box and 2) allowing to mix DTL and Jinja2 templates; then 3) decoupling DTL and 4) rewriting Django builtin templates in Jinja2. After doing it, we can reconsider eventually switching to Jinja2. On Monday, February 10, 2014 9:56:37 PM UTC+1, Aymeric Augustin wrote: > 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? The only problem I can see is that Jinja supports 3.3+ while Django 1.8 will support 3.2 (I guess). So 1) we need to drop support for 3.2 in Django 1.8 or 2) we need to tamper with Jinja2 to support 3.2 (Armin is not going to help us do it). -- 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 [email protected]. To post to this group, send email to [email protected]. 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/e609e422-7434-462d-8b2f-dae186c0de75%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
