For any refactoring of the template engine, going to jinja2, etc... it would very much help to look at this ticket first: https://code.djangoproject.com/ticket/20434
It's a backwards compatible patch, which allows template tags to be written in a much more declarative way, without exposing any internals of the parser in the API. If all template tags are eventually rewritten in this system, we could deprecate the old way and have a chance to play with the parser. (But even if we wouldn't depracate old template tags. It's still cleaner.) This would probably also allow the same template tags of Django to be used by Jinja2. I wrote that patch a year ago, so not sure whether it still merges. Le dimanche 9 février 2014 23:53:36 UTC+1, Russell Keith-Magee a écrit : > > > Hi Curtis, > > If true, this would certainly be a reasonable improvement. > > However, I'm not sure it would be a great GSoC project. > > This would have to be posed as a "optimise the template language" project, > which is problematic when we don't know for certain ahead of time where the > problems lie. We're not likely to accept a 12 week fishing expedition, > because there's a possibility that the student will run out of things to > fix after 2 weeks. > > The only way that this would be an acceptable GSoC project would be to > present a pre-analysis that demonstrated that there was 12 weeks worth of > things than needed to be optimised. However, my experience with > optimisations of this sort has been that *finding* the problem is usually > 90% of the work. Once you know *what* is slow, cleaning up a code path or > caching a slow lookup is comparatively easy. > > However, if someone wants to look for sources of optimisation outside of > GSoC, I'd encourage them to do so. > > Yours, > Russ Magee %-) > > On Sun, Feb 9, 2014 at 8:56 AM, Curtis Maloney > <[email protected]<javascript:> > > wrote: > >> 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 >> <[email protected]<javascript:> >> > wrote: >> >>> >>> On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela >>> <[email protected]<javascript:> >>> > 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] <javascript:>. >>> To post to this group, send email to >>> [email protected]<javascript:> >>> . >>> 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 [email protected] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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. >> > > -- 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/fc6bc89b-83ca-4875-bbbf-7bc099b6fbc2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
