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. > 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 [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/CAJxq8489OcnOg_KE6PsAghqF6smSY8hRW3gKsmoGT%2Bec1kBMiw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
