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
