On Sun, Feb 16, 2014 at 12:43 AM, Christopher Medrela < [email protected]> 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, but DTL will remain the "blessed" option. > As a broad statement, this sounds fine; but what does this mean in practice? What does "out of the box" support look like? > Secondly, Django will allow to mix DTL and Jinja2 templates (so you can > include/inherit DTL template from Jinja2 one and vice versa). > Including doesn't sound like it would be any problem, but inheriting? Is that really going to be possible? > > 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. > > 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? > I think the broad feature is useful; I can't comment as to whether it would make the lives of any existing Django-Jinja users any easier. 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2? > Django 1.6 and 1.7 both support 3.2; we haven't had the project-level discussion about deprecating 3.2 support. Historically, this would have been based on the usage of Python 3.2 in the wild, driven primarily by operating systems that shipped 3.2 as the default. That's not going to apply here. I'm not sure how we'd judge the rate of 3.2 adoption in practice. 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we > ready for this? > I think we are. Pip and setuptools handle dependencies really well; if we don't want to add it as a default dependency, we can easily check for an ImportError when Jinja support is enabled and give an appropriate error message, same as we do for YAML support. > On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote: >> >> 2014-02-11 13:42 GMT+01:00 Christopher Medrela <[email protected]>: >> >> >>> 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. >> >> While his arguments are technically correct, I disagree with his >> conclusions >> because he's speaking with the point of view of an expert maintaining >> libraries at the boundary between unicode and bytes (like werkzeug). >> However, >> most Python users aren't experts and aren't maintaining such libraries. >> In my >> experience working with Python programmers ranging from intern to >> veteran, the >> unicode model of Python 3 is a strict improvement over Python 2 in terms >> of >> pitfalls hit in day-to-day programming. YMMV. >> >> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ >> >> -- >> Aymeric. >> > > OK, so Armin finds Python 2 better than Python 3. But why is it at odds > with > Django? He didn't say that he is not going to support Python 3. So where is > the risk that concerns you? > For my part, my concern is that the tone of his discussions and comments about Python3 suggests that while he currently supports Python3, he does so begrudgingly, and he might, at some point in the future, stop. That would put Django in a precarious position. 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/CAJxq8493xryKMEjAzHO_Qbp1k9vn-zWBnS_1iw4i%2Bdq8ng34wQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
