Re: [GSoC] Switching to Jinja2 proposal

[Donald Stufft]

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 will allow to mix DTL and Jinja2 templates (so you can
>> include/inherit DTL template from Jinja2 one and vice versa).
>> 
>> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
>> Django
>> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
>> Python code to Jinja2 templates.
> 
> This sounds reasonable to me.
> 
>> After that all, we could start again the war DTL vs Jinja2, but please focus
>> on the new proposal now.
>> 
>> Questions are:
>> 
>> 1) What do you think about the new proposal? Would it be useful?
> 
> Yes, as long as Jinja2 is a hard dependency, such that we can rely on
> its availability for internal Django use (form widgets).
> 
>> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
> 
> Donald might be able to offer better hard numbers based on e.g. PyPI
> usage, but my impression is that usage of 3.2 is very low, and dropping
> it for 1.8 would not be a major problem.

These numbers are about a month old, but https://gist.github.com/dstufft/8455306

> 
>> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>>   ready for this?
> 
> I think so, yes.
> 
> Carl
> 


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [GSoC] Switching to Jinja2 proposal

[Carl Meyer]

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
> include/inherit DTL template from Jinja2 one and vice versa).
> 
> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
> Django
> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
> Python code to Jinja2 templates.

This sounds reasonable to me.

> After that all, we could start again the war DTL vs Jinja2, but please focus
> on the new proposal now.
> 
> Questions are:
> 
> 1) What do you think about the new proposal? Would it be useful?

Yes, as long as Jinja2 is a hard dependency, such that we can rely on
its availability for internal Django use (form widgets).

> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?

Donald might be able to offer better hard numbers based on e.g. PyPI
usage, but my impression is that usage of 3.2 is very low, and dropping
it for 1.8 would not be a major problem.

> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>ready for this?

I think so, yes.

Carl



signature.asc
Description: OpenPGP digital signature

Re: [GSoC] Switching to Jinja2 proposal

[Carl Meyer]

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's done in Jinja2?
Or is this preference for DTL entirely a matter of theoretical concern
about what others might do given the increased power of Jinja2?

I ask because the latter is all I've so far heard, and I have a hard
time imagining cases of the former where the DTL approach couldn't
easily be emulated in Jinja2.

> b) The Python3 support issue is a lingering concern
> 
> c) There is a lot of legacy code and tutorials that need to continue to
> work as is.
> 
> This is an area where there is a lot of benefit to moving slowly, IMHO.
> We're talking about a major part of the Django experience; Introducing a
> new option *and* switching to it in a single release sounds like a
> recipe for confusion to me.
> 
> As I see it, there are three possible options here:
> 
>  1) Add Jinja2 as a supported option, but stick with DTL as the default.
>  2) Add Jinja2 as a supported option, and indicate that long term, we're
> going to switch to Jinja as the default
>  3) Add Jinja2 as a supported option and move to it immediately as the
> default.

I agree that that there is no harm in moving slowly (apart from the
added burden of maintaining support for two template engines for a
period of time).

From my perspective, the most important benefit comes not when Jinja2
becomes the default/documented option (although I do favor moving in
that direction), but when it becomes a guaranteed-available option, such
that we can use it internally in Django performance-sensitive template
renderings (i.e. form widgets). If we don't achieve even that in the
first iteration, then we haven't achieved much that isn't already doable
via third-party adapters such as jingo or django-jinja.

Carl



signature.asc
Description: OpenPGP digital signature

Re: [GSOC] Improving the Test-Suite

[Akshay Jaggi]

I'm so sorry. Was busy with some assignments. I will look into all the 
mentioned points and reply back as soon as 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/76827fb2-7709-4c10-981c-befb407f3870%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The unsettings project

[Aymeric Augustin]

Hi Schuyler,

On 14 févr. 2014, at 15:18, Schuyler Duveen  wrote:

> TLDR: Django modules should work as libraries (e.g. ORM, mail, etc).  "from 
> django.conf import settings" bootstrap undermines this.

> My use-case is Django's awesome (yes, I know opinions differ), simple-to-use 
> ORM.

For the ORM, settings aren't the primary concern. The biggest problem is 
setting up relations between models. This needs to be done at some point before 
you start using models.

Before Django 1.7, the app cache took care of that at some ill-specified and 
project-dependant point. During the app-loading refactor, we recognized that 
such an important step couldn't be left to chance and we introduced an explicit 
bootstrap, `django.setup()`.

Given the current implementation of `django.setup()`, it seems possible to 
inject the settings there in another form that a Python module, if that's what 
you're after. See 
https://github.com/django/django/blob/master/django/__init__.py#L11-L21.

It seems to me that you haven't attacked the right problem for what you're 
describing as your primary use case. (That's why I've been asking for a 
mailing-list discussion since September.)

Besides, you need a plan to replace `django.setup()`.

> For the first trial at this approach, we tried out utils.timezone:
> https://github.com/SlashRoot/django/blob/33c49245032115cf3fd6534d5a55313435419ffb/django/utils/timezone.py#L302
> 
> and it seemed to have worked, so we moved on to django.core.mail, and other 
> modules.

All the discourse around unsettings is based on the assumption that it's an 
incremental improvement that may provide some other benefits in the future.

However, the current results aren't looking so good to me:
- The new APIs are weird: functions end up with additional keywords arguments 
purely based on their implementation. This isn't a good way to design and API. 
(I assume that the goal of unsettings is to make these APIs public.)
- It makes the code more complex: every contributor to Django will have to 
learn a new way to inject settings into functions. In order to keep the barrier 
to contributing to Django low, I'm not fond of such idiosyncrasies.

Also, benefits still look quite hypothetical, if not theoretical. I'm worried 
about beginning a path without a convincing explanation of why it isn't a 
dead-end. In the past, we've hit dead-ends on projects much better planned that 
this one, eg. mitsuhiko's "template compilation" GSoC.

That makes me -1 on the concept for now. I don't believe it beats the status 
quo. To change my vote, I would need:
- a description of how you plan to deal with django.setup() -- it seems more 
complicated than dealing with settings;
- an explanation of what comes after we replace every "settings.FOO" with 
"@unsettings(FOO=...)";
- some thoughts of why we're comfortable maintaining the resulting public APIs 
in the long term.

I have much more to say but I've tried to summarize my thoughts in this email. 
I hope this helps.

-- 
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/5FB6B896-8210-48DB-9942-A190BDCFFFC0%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.