Re: [GSoC] Switching to Jinja2 proposal

On Wednesday, March 18, 2015 at 4:44:05 PM UTC+1, Asif Saifuddin wrote: > > Hi, chris, > > So as django have the jinja 2 support out of the box what do you think the > direction of the ticket? https://code.djangoproject.com/ticket/15667 > > should the form rendering based on jinja2? or whats on ou

Re: [GSoC] Switching to Jinja2 proposal

Hi, chris, So as django have the jinja 2 support out of the box what do you think the direction of the ticket? https://code.djangoproject.com/ticket/15667 should the form rendering based on jinja2? or whats on our mind? If you guide me with some direction then I might go for the ticket. looking

Re: [GSoC] Switching to Jinja2 proposal

On Sunday, March 23, 2014 11:51:06 AM UTC+1, Gwildor Sok wrote: > > So, there won't be a GSoC project for this, but it would be a shame to let > the lengthy discussion and momentum generated go to waste. Can a decision > on this matter be made and implemented regardless of the GSoC projects? > I

Re: [GSoC] Switching to Jinja2 proposal

So, there won't be a GSoC project for this, but it would be a shame to let the lengthy discussion and momentum generated go to waste. Can a decision on this matter be made and implemented regardless of the GSoC projects? Personally, I'm all for it, mostly because of the speed gained, which would

Re: [GSoC] Switching to Jinja2 proposal

Hello! I'm sorry for such long time without any feedback. Unfortunately, I'm not going to send Django proposal. My original plan was to send two proposals: one for Django and one for Breeze (Scala numerical processing library) but I lack time and I will focus on Breeze. Therefore, I won't have eno

Re: [GSoC] Switching to Jinja2 proposal

Yah... my oops ... I was reading on my phone and missed the link :) On 25 February 2014 21:03, Christopher Medrela wrote: > The link is here: http://pastebin.com/DWjE1axV > > It times only rendering -- templates are parsed and cached in the setup. > > > On Tuesday, February 25, 2014 8:34:14 AM U

Re: [GSoC] Switching to Jinja2 proposal

> > What kind of support do you except for third-party template tags? Suppose, > that > `cycle` tag is not builtin. Would it be acceptable to write sth like that: > > dtl cycle '1' '2' as rows > > It could be quite easily implemented as a Jinja2 extensions. Of course, I > guess > that you'd

Re: [GSoC] Switching to Jinja2 proposal

The link is here: http://pastebin.com/DWjE1axV It times only rendering -- templates are parsed and cached in the setup. On Tuesday, February 25, 2014 8:34:14 AM UTC+1, Curtis Maloney wrote: > > Did I miss the link to your benchmark code? > Does it time just rendering, or parsing also? > -- > Sen

Re: [GSoC] Switching to Jinja2 proposal

On February 25, 2014 9:43:49 AM AEDT, Christopher Medrela wrote: >I've made some benchmarks. The results are: > >jinja2 empty for 0.028 s >jinja2 include1.094 s >django empty for 0.435 s >django include2.134 s > >Where "empty for" is an empty loop repeated 50 times: > >{% for i in r

Re: [GSoC] Switching to Jinja2 proposal

I must admit to being conflicted on this project. I'd love to see the measurements and profiling involved in establishing how much "faster" Jinja2 is, mostly to see where DTL could do with some love... However, I don't believe for most people their templates represent enough of a time cost to mak

Re: [GSoC] Switching to Jinja2 proposal

I've made some benchmarks. The results are: jinja2 empty for 0.028 s jinja2 include1.094 s django empty for 0.435 s django include2.134 s Where "empty for" is an empty loop repeated 50 times: {% for i in range_ %} {% endfor %} And include is a similar template where the loop body

Re: [GSoC] Switching to Jinja2 proposal

Hi Christopher, > ... checks the template extension and dispatch to > corresponding function from `django.dtl` or `jinja2`. > The mechanism for distinguishing the two kinds of template needs to be more flexible. For example, let's say I want to override a third-party template with my own Ji

Re: [GSoC] Switching to Jinja2 proposal

On Fri, Feb 21, 2014 at 3:22 PM, Camilo Torres wrote: > - Then, we can create dummy implementations of `render_to_response` (and >> all >>other functions) that checks the template extension and dispatch to >>corresponding function from `django.dtl` or `jinja2`. >> > > Hello, > > Could thi

Re: [GSoC] Switching to Jinja2 proposal

> > - Then, we can create dummy implementations of `render_to_response` (and > all >other functions) that checks the template extension and dispatch to >corresponding function from `django.dtl` or `jinja2`. > Hello, Could this create a little problem for the people in charge of the tem

Re: [GSoC] Switching to Jinja2 proposal

I'm sorry for such long time without any reply, but I was investigating possible approaches of mixing Django and Jinja2 templates. On Sunday, February 16, 2014 1:08:49 AM UTC+1, Russell Keith-Magee wrote: > > > On Sun, Feb 16, 2014 at 12:43 AM, Christopher Medrela > wrote: > >> My last post was

Re: [GSoC] Switching to Jinja2 proposal

On Feb 16, 2014, at 4:23 PM, Carl Meyer wrote: > Hi Christopher, > > On 02/15/2014 09:43 AM, Christopher Medrela wrote: >> 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 w

Re: [GSoC] Switching to Jinja2 proposal

Hi Christopher, On 02/15/2014 09:43 AM, Christopher Medrela wrote: > 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 > inc

Re: [GSoC] Switching to Jinja2 proposal

Hi Russ, On 02/15/2014 05:16 PM, Russell Keith-Magee wrote: > a) Some of us prefer DTL to Jinja2 :-) Just as a point of clarification: have you used Jinja2 for a non-trivial project, and are there specific areas where you, personally, for your own use, prefer how you do something in DTL vs how it

Re: [GSoC] Switching to Jinja2 proposal

On Sun, Feb 16, 2014 at 1:12 AM, Donald Stufft wrote: > > On Feb 15, 2014, at 11:43 AM, Christopher Medrela > 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 p

Re: [GSoC] Switching to Jinja2 proposal

On Sun, Feb 16, 2014 at 12:43 AM, Christopher Medrela < chris.medr...@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 > s

Re: [GSoC] Switching to Jinja2 proposal

On 15 Feb 2014 18:13, "Donald Stufft" wrote: > > > On Feb 15, 2014, at 11:43 AM, Christopher Medrela 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.

Re: [GSoC] Switching to Jinja2 proposal

On Feb 15, 2014, at 11:43 AM, Christopher Medrela 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,

Re: [GSoC] Switching to Jinja2 proposal

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

Re: [GSoC] Switching to Jinja2 proposal

In addition, Django implements the (non-standard) __html__ protocol: https://code.djangoproject.com/ticket/7261. I believe escaping will work correctly without many, if any, changes. -- Aymeric. On 12 févr. 2014, at 22:40, Marc Tamlyn wrote: > Point of order: Jinja2 does now have autoescap

Re: [GSoC] Switching to Jinja2 proposal

On 02/12/2014 02:25 PM, Curtis Maloney wrote: > On 12 February 2014 21:29, Gwildor Sok One downside I can think of is that Jinja does not escape variables > by default, which might become a XSS security issue. > > That's quite a large downside! Jinja2 supports autoescape-by-default, it's

Re: [GSoC] Switching to Jinja2 proposal

Point of order: Jinja2 does now have autoescaping ( http://jinja.pocoo.org/docs/extensions/#autoescape-extension) Do not take this as any opinion on the matter On 12 February 2014 21:34, Donald Stufft wrote: > Crate had one, i'd have to pull it out but it was a pretty simple > template. The st

Re: [GSoC] Switching to Jinja2 proposal

Crate had one, i’d have to pull it out but it was a pretty simple template. The sticking point was it had a 30k item loop which was significantly faster in Jinja2. On Feb 12, 2014, at 4:25 PM, Curtis Maloney wrote: > At this point someone should start asking for real-world examples with > meas

Re: [GSoC] Switching to Jinja2 proposal

On 02/12/2014 02:25 PM, Curtis Maloney wrote: > At this point someone should start asking for real-world examples with > measurements. > > I'm personally of the "let's see if we can improve DTL first, then > revisit the question" stance. > > But in order to show any improvements, we must have tim

Re: [GSoC] Switching to Jinja2 proposal

At this point someone should start asking for real-world examples with measurements. I'm personally of the "let's see if we can improve DTL first, then revisit the question" stance. But in order to show any improvements, we must have timings for the current tool. Can people who've suffered slown

Re: [GSoC] Switching to Jinja2 proposal

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 pjaxto replace content on the page, but in the backend this is still do

Re: [GSoC] Switching to Jinja2 proposal

I'm not a django-developer, but I'm creating a lot of applications with Django and I would never want to switch to Jinja2. Why? The first thing is that Django Templates are simple to understand, they are not formed as a new DSL or a Programmable way of a Template language. Their Syntax is clear a

Re: [GSoC] Switching to Jinja2 proposal

2014-02-11 13:42 GMT+01:00 Christopher Medrela : > What did Armin said about Python 3 exactly? > He wrote an extensive argumentation about "why Python 2 [is] the better language for dealing with text and bytes" [1] as well as a number of tweets and a few other blog posts along the same lines. W

Re: [GSoC] Switching to Jinja2 proposal

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 > wrote: > >> Hello! GSoC 2014 is coming and I'm thinking about issue to work on. >> >> The template system is one of th

Re: [GSoC] Switching to Jinja2 proposal

Hi Aymeric 2014-02-10 21:56 GMT+01:00 Aymeric Augustin < aymeric.augus...@polytechnique.org>: > On 10 févr. 2014, at 20:16, Carl Meyer wrote: > > > I've proposed it before, and not in jest. Though perhaps not fully > > seriously either, as full seriousness would mean supplying a patch. > > I'v

Re: [GSoC] Switching to Jinja2 proposal

On 11 févr. 2014, at 03:00, Russell Keith-Magee wrote: > 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

Re: [GSoC] Switching to Jinja2 proposal

Sent from my iPad > On Feb 10, 2014, at 7:00 PM, Russell Keith-Magee > wrote: > > >> On Tue, Feb 11, 2014 at 9:31 AM, Luke Sneeringer wrote: >>> On Feb 10, 2014, at 12:16 PM, Carl Meyer wrote: >>> >>> It's a problem that we are unable to do things >>> that would otherwise be no-brainers (

Re: [GSoC] Switching to Jinja2 proposal

On Tue, Feb 11, 2014 at 9:31 AM, Luke Sneeringer wrote: > On Feb 10, 2014, at 12:16 PM, Carl Meyer 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

Re: [GSoC] Switching to Jinja2 proposal

On 11 February 2014 12:31, Luke Sneeringer wrote: > On Feb 10, 2014, at 12:16 PM, Carl Meyer 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)

Re: [GSoC] Switching to Jinja2 proposal

> On Feb 10, 2014, at 12:16 PM, Carl Meyer 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 s

Re: [GSoC] Switching to Jinja2 proposal

On 10 févr. 2014, at 20:16, Carl Meyer wrote: > I've proposed it before, and not in jest. Though perhaps not fully > seriously either, as full seriousness would mean supplying a patch. I've heard an ex-BDFL accepting the idea. The other ex-BDFL was there and he didn't throw the first one through

Re: [GSoC] Switching to Jinja2 proposal

Hi Chris and Russ, On 02/08/2014 05:11 PM, Russell Keith-Magee wrote: > > On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela > mailto:chris.medr...@gmail.com>> wrote: > > Why not switching to Jinja2? I thought that somebody else proposed > this idea > but I couldn't find any discuss

Re: [GSoC] Switching to Jinja2 proposal

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

Re: [GSoC] Switching to Jinja2 proposal

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

Re: [GSoC] Switching to Jinja2 proposal

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 ben

Re: [GSoC] Switching to Jinja2 proposal

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

Re: [GSoC] Switching to Jinja2 proposal

On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela 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 > coul

[GSoC] Switching to Jinja2 proposal

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