Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

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 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, 

Re: [GSoC] Switching to Jinja2 proposal

[Russell Keith-Magee]

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
> 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 

Re: GSoC query

[Russell Keith-Magee]

On Sun, Feb 9, 2014 at 5:02 AM, Christopher Medrela  wrote:

> There is a list of ideas [1] and both improving aggregates and annotations
> as well as improving error messages are listed there, so I suppose these
> ideas are still open.
>

They're definitely still "open" in the sense that the problems still exist,
and the projects haven't been allocated to a specific student.


> Google doesn't allow you to submit your proposal before March 10, but the
> submission is only a formality and this doesn't mean you can't work at your
> proposal. The most important thing is that you should discuss your proposal
> with Django community before submission, because you will be given many
> constructive feedback that will help you make your proposal better and
> improve chances of being accepted. My experience is that it's better to
> start as early as possible and not to hesitate to publish proposal.
>
> AFAIK, there is no problem if there is more than one student working on
> the same idea.
>

There's no limit on multiple students working on the same *proposal*, but
ultimately, we're not going to pick two students to work on the same
project. This is for administrative reasons -- GSoC requires us to evaluate
students as individuals, and if two students are collaborating on a
project, or if one student's work is dependent on another in some way, then
this becomes a lot more difficult.

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

[GSoC] Switching to Jinja2 proposal

[Christopher Medrela]

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.

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!

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.

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.

I'd like to hear your opinion. Feel free to comment!

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?

-- 
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/a6a176b2-b380-4ba7-8bad-0f3d6719cb03%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC query

[Aymeric Augustin]

On 8 févr. 2014, at 22:02, Christopher Medrela  wrote:

> AFAIK, there is no problem if there is more than one student working on the 
> same idea.

In practice, I don't think we would allocate two slots to the same idea. 
However, an proposal that wasn't thoroughly discussed on this mailing-list has 
almost no chance of being selected. That makes it easy to detect possible 
conflicts. For this year's GSoC, I haven't seen any serious proposal yet.

-- 
Aymeric.




-- 
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/F4C810EF-5770-4AAA-B1F5-BDBFDD95DD1D%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC query

[Christopher Medrela]

There is a list of ideas [1] and both improving aggregates and annotations 
as well as improving error messages are listed there, so I suppose these 
ideas are still open. 

Google doesn't allow you to submit your proposal before March 10, but the 
submission is only a formality and this doesn't mean you can't work at your 
proposal. The most important thing is that you should discuss your proposal 
with Django community before submission, because you will be given many 
constructive feedback that will help you make your proposal better and 
improve chances of being accepted. My experience is that it's better to 
start as early as possible and not to hesitate to publish proposal.

AFAIK, there is no problem if there is more than one student working on the 
same idea.

Disclaimer: I'm not a core dev neither GSoC admin, but I was GSoC 
participant (as a student) last year.

[1] https://code.djangoproject.com/wiki/SummerOfCode2014

-- 
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/0e3aaa96-0a5f-4948-b9d3-95522b9b1795%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

`prefetch_related` for non-homogenous data and "weak" lookups through GFKs

[andrew.pashkin]

With GenericForeignKey functionality, it is possible to refer to arbitrary 
model. Let's ay we have Like model, which is naturally may refer to many 
types of data (blogposts, users, photos, comments, etc). And so it is 
desireable to be able to perform such lookups: 

Like.objects.prefetch_related('content_object__followers', 
'content_object__people_on_photo')

where followers is the field of User model and people_on_photo the field of 
Photo model.

Currently .prefetch_related will raise an error like 

Cannot find field `followers` on Photo object. 

because currently it is assumed that lookups are 'strict', and data for 
each lookup is homogenous (stealed the word form comment in sources :). 
So I think it would be nice to implement feature for non-strict lookups in 
addition to #17001‎.


-- 
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/19fa19bd-3c8d-4b8f-b711-ba4167af1485%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

GSoC query

[anubhav joshi]

Well I am thinking to work on aggregates and annotation, and improving the 
error messages part.
I just want to know if these are still open.
And what is the procedure if more than one student submit similar proposals 
or what if one submits it before then whether it remains open for another?
Can we start submitting proposals before March 10 or do we have to wait 
till then?

-- 
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/896f1206-dc91-49f7-b2a5-c5601f40dc5a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

GSoC Project Ideas

[anubhav joshi]

Well I am thinking to work on aggregates and annotation, and improving the 
error messages part.
I just want to know if these are still open.
And what is the procedure if more than one student submit similar proposals 
or what if one submits it before then whether it remains open for another?

-- 
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/a6367a46-8a8b-4cba-81a1-013d9e714c73%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Multiple dates in single date field

[Russell Keith-Magee]

On Sat, Feb 8, 2014 at 2:27 PM, Harjot Mann wrote:

> Is it possible to add more than one date in a single date field in django?
> How can a user do this if one wants to add?
>

This isn't really an appropriate question for django-developers. If you're
looking for help using Django, you should be asking on django-users.

However, even if you do this, you're not going to get many answers, because
this sort of structure isn't something that relational databases do (at
least, not without using vendor-specific extensions). There isn't anything
builtin to Django to support "list" types, other than the many-to-one
relation between two models.

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/CAJxq848uEbbu%3Dz_JTfc7hfaAhMEmm%3DgxK%2BrhPAduGtdHU41LJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.