I don't know if anyone's noticed, but the templating language seems
(at least from a usage standpoint) to be a lot like a Lisp
interpreter.
I know that sounds completely weird and random, but it's true. It's
like a very small subset of Scheme or something (the small subset
thing is necessary because you're not trying to put too much logic in
the template). I suppose the main difference is that blocks are
started and ended with explicit {% sometag %} and {% endsometag %}
statements instead of opening and closing parentheses.
If you need to refactor any of it, you might want to look at some
implementations of Lisp and steal some ideas.Just a thought from a Lisper :) Regards, Zack On Sep 18, 12:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-17 at 14:42 +0100, Ben Ford wrote: > > I take it that most are aware of: > > >http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-djang... > > > It seems like a very well thought out and thorough write up. > > Um .. welll. :-( > > Parts of it are very well thought out and if it had been a post on "how > Jinja works" it would have been excellent. Other parts are completely > unconstrained by facts or acknowledgement that Django's standard > templates and Jinja's ones have different goals (which is important, > since this isn't an apples to apples comparison at all). So that the > flip side is on the record, here's my single contribution to it: > > The good news is that, as far as I can see, all the actual bugs he notes > are already in tickets. I went through and checked quickly yesterday and > found all but one, which I'm pretty sure is in there, so I'll look again > today. > > Whilst reading that, keep in mind that Armin apparently misunderstands > (or possibly just omits to clearly state) what a template object > instance is in Django. It's a state machine for rendering templates and > includes the current state as well as the transitions. This isn't an > invalid or particularly novel approach to executing a domain specific > language. In fact, it makes a lot of sense if you want to write > self-contained node-based state instances. Jinja and Django templates > have different compilation strategies and return different types of > objects and the difference is a vital distinction in any discussion of > appropriate usage. The blog post appears to imply that it would be > natural for any random data structure to be used as a global variable > (by extrapolation, since he doesn't establish that a Template instance > -- not a class, the instance of a compiled template -- is special in any > sense, so it must be somehow "normal") and that those structures will > work beautifully when multiple threads cause its internal state to be > modified. > > This has two problems: (1) it's pretty much false by default (Python != > Haskell, Erlang, etc and mutable objects are very normal in Python), and > (2) it would imply that using lots of globals to store stuff in > multi-threaded programs is a good idea that people should be doing more > often. > > There's a name for that sort of programming style and it's not > "Excellent, Maintainable Code". :-) > > Using the same logic, Python is not thread-safe at all and shouldn't be > used, since lists, dictionaries, sets, and pretty much any random > instance of a class object contain state in the instance that will > change upon use. Tuples and strings are specially noted to be immutable > and so are usable in those situations without extra locking, but they're > special-cases, not the norm, in a pass-by-reference language. Using > module-level globals sparingly is something we certainly encourage. > > Fortunately, this isn't a real issue, since there's nowhere that we > suggest the assumption of immutability would be valid (and, really, a > decent programmer is going to know that any arbitrary data structures > have the same behaviour unless it's noted as immutable; minimal > experience says that making assumptions contrary to that always leads to > trouble). You create the template object as part of a view and render it > and things are (mostly -- see next para) fine. There's no real need to > put template instances into globals. > > The "mostly" bit is because we do have some reset-ability issues with > things like the cycle tag -- so rendering it multiple times in the same > thread of execution, such as creating mass mail, will lead to differing > results. > > Also, so that it's on the record: Armin denigrating Eric Holscher for > ticket #7501 was a low-blow for multiple reasons. One being that Armin > either misunderstood or ignored the type of object that a Template > instance is, as noted above. Another being that nominally avoiding > mentioning specifics whilst giving enough information that somebody > could easily find it out anyway is simply sleazy. It devalues Eric's > work for that part of the audience who don't know the history and makes > the author of the piece just look small. To fill in the missing pieces, > I explicitly asked Eric to change the title at the Lawrence Sprint, as I > was busy doing something else at the time and had been meaning to change > it for a while and Eric was going through doing the scut work of making > the changes through the Web browser interface whilst Jacob and I fed him > decisions on various points. I made this change in full awareness of the > difference between multi-threaded and multi-run use-cases and knowing > that Template instances are just like lists, dictionaries, > sets, ...(insert 150 other data structures here). > > All the bits in that blog post about Jinja, once understood in the > context of why Jinja is a different templating approach to Django, were > well done in that article. Reading the Jinja source is a pretty > interesting thing to do, too and people should definitely play with the > language if they haven't already. But it's not a one-for-one replacement > for Django templates, nor is it a superset of functionality in either > direction. It has different goals and neither Jinja nor Djangos' goals > are invaildated by the other existing. > > The bugs noted in Django templates are things we've noted down and > Johannes changes address a large number of them. We've always accepted > speed improvements that don't completely break things, but we also > realise that template rendering is just one component of the timeslice > for a request and isn't the major piece unless your net time is pretty > tiny anyway. With sensible caching strategy and real-world data and > computation stuff, the amortised effect is that it's "fast enough", for > most cases and making it possible to easily enough use a different > templating language when it's not. That's a pretty good goal. Django > ships with a template language for designers, not for Python > programmers; another large difference between Django and Jinja > templates, leading to the somewhat-perceived dichotomy over "logic in > templates" (although in a lot of cases the big arguments people have > come down to which template tags and filters should ship by default). > > It's always nice when somebody sits down and write out an holistic state > of play of a particular portion of anything. It's very encouraging when, > reading through, you realise that there aren't any really big surprises > in the factual areas and it helps clarify where the differences of > opinion are. Sanity checks of that nature cannot be undervalued. They > can be written in a less confrontational style, however. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
