On Thu, Mar 4, 2010 at 6:58 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Fri, Mar 5, 2010 at 12:26 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: >> On Thu, Mar 4, 2010 at 3:41 AM, Russell Keith-Magee >> <freakboy3...@gmail.com> wrote: >>> On Thu, Mar 4, 2010 at 7:29 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > >>>> Templates will be compiled by turning each template into a series of >>>> functions, >>>> one per block (note that the base template from which other templates >>>> extend is >>>> a single function, not one per block). >>> ... >>>> After an intermediate representation is created a compiler is invoked which >>>> translates the IR into Python code. This handles the details of Django >>>> template >>>> scoping, spilling variables in the event of conflicts, and calling >>>> template tag >>>> functions. >>> >>> You don't ever say this explicitly, but I presume that the plan is to >>> do this as an in-memory construction -- that is, the intermediate >>> representation is handled in-memory, not as a python file on disk. >>> You're proposing to writing a (2 pass?) compiler, not a code >>> generator, right? >>> >> >> My plan was an in-memory construction, but there's no reason once we >> have the infrastructure in place that we couldn't generate templates >> to disk. As for a compiler vs. a code generator, a compiler *is* a >> code generator, so I'm not sure I see the distinction being made. > > Ok - sure - a compiler is a code generator. What I'm driving at is > that you're not proposing that we move to a Cheetah-style model. The > output of the compiler isn't something the end user should ever need > to see, and won't ever see under normal circumstances. The compiled > output isn't something the user will (under normal conditions) have > the opportunity of modifying and editing, and they won't need to have > makefiles or some similar construct to make sure their compiled > templates are up to date. Django template use isn't going to devolve > into "import mytemplate". >
That's correct, although as I said there's no reason someone couldn't utilize the compilation APIs to write them out to disk and do "import mytemplate". >>>> To provide an optimal solution we must know which variables a given >>>> template >>>> tag needs, and which variables it can mutate. This can be accomplished by >>>> attaching a new class attribute to ``Nodes`` and passing only those values >>>> to >>>> the class, (instead of the full context dictionary). Subsequently, we would >>>> only need to mirror a few given values into the locals, and since these are >>>> known names, we avoid degrading the local lookups into dictionaries. >>>> Old-style >>>> ``Nodes`` will continue to work, but in a less efficient manner. >>> >>> The term "less efficient" needs clarification here -- less efficient >>> than a compiled node that has been specifically optimized for >>> compilation, or less efficient than existing template rendering? It's >>> completely understandable if a node doesn't render as fast as it's >>> optimized and compiled counterparts, but I would consider it a failure >>> if a compiled template resulted in a slowdown when compared to >>> existing non-compiled rendering speed. >>> >> >> less efficient than existing rendering, for that specific node. This >> is because the Context dictionary would have to be rematerialized for >> each and every old-style node in the template. > > That's what I expected; I just wanted to make sure we were on the same page. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
