If I follow you are saying that it is lispy in that flow control
statements and functions are handled just the same way(meaning you can
define your own statements if you like)?
On Sep 17, 8:02 pm, zvoase <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
