Can I suggest a 3) to this? After getting involved with the internals of the template engine recently, I came to the suspicion that a lot of the speed issues come from highly defensive coding.
Now, this is generally to be expected when safety is more important than speed, but I am moderately firm of the opinion that some careful analysis of the template code could help reveal places where the same guard [such as mark_safe, force_text, etc] is being applied repeatedly but could be avoided. So my (3) to this is to analyse the template code paths sufficiently to be able to identify places where these guards can be omitted safely. -- Curtis On 9 February 2014 11:11, Russell Keith-Magee <russ...@keith-magee.com>wrote: > > On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela < > chris.medr...@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 >> 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. > > >> Why not switching to Jinja2? I thought that somebody else proposed this >> idea >> but I couldn't find any discussion; so, please, point me to the >> discussion if >> the idea was discussed, otherwise let's discuss it! >> > > It's been proposed in jest, and it's been accepted in jest as well :-) > However, I don't think there's been a serious proposal to this effect. > > >> 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. > > >> The second big problem is that switching is a big change and backward >> compatibility matters. We will need to support both the deprecated Django >> template system and the new one. However, it doesn't mean double work -- >> we >> don't need to implement new features for the deprecated system, only bug >> fixes >> will be required. Also note, that a lot of companies uses Jinja2 and >> switching >> from third-package Jinja2 to Jinja2-builtin-Django isn't an enormous >> change at >> all. >> > > Untrue. It *can* be a *very* big change. One of the biggest problems is > backwards compatibility for custom template tags. There are a lot of these > out there in the wild, and the way Django defines custom template tags is > one of the major reasons that a bytecode approach to Django templates is > difficult. > > >> I'd like to hear your opinion. Feel free to comment! >> > > Personally, I'm -0 on this proposal as described. > > 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. > > I'd be a more supportive of two different spins on this project idea: > > 1) Try to pick up where the 2012 GSoC project left off, and continue the > work to byte code compile Django's templates. However, this project is > unlikely to get off the ground without a concrete proposal to get around > the problems encountered the first time around. > > 2) Work on the internals of Django to decouple the template engine, so > that (a), Django's template language is a standalone in the same way that > Jinja2 is, and/or (b) there's a clean interface so that it's possible to > define a clean Jinja2 module that you can drop into your Django stack. > > A good solution for (2) would set the groundwork for a *long term* > transition to Jinja2 templates, but would also allow long term backwards > compatibility, as the Django template language could be maintained long > term, even if it is dropped as an officially supported option by Django > itself. > > 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. > > Yours, > Russ Magee %-) > > -- > 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-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@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/CAJxq8489OcnOg_KE6PsAghqF6smSY8hRW3gKsmoGT%2Bec1kBMiw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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. For more options, visit https://groups.google.com/groups/opt_out.
