On Dec 3, 2005, at 5:44 AM, mario ruggier wrote:

> Just wondering... as a qpy html template in practice always returns
> with a call to:
>
>       h8.from_list( template_contents )
>
> This means that in a hierarchy of qpy html template calls, each
> call is building a list, then returning its joined contents as a h8
> string, potentially implying creating and throwing away many
> intermediate strings.
>
> Would there be any gains from either of these possibilities:
>
> - Have a nested qpy html template always append to the caller's
> template list, thus a "page" (or whatever, a sizable chunk
> initiated by an "entry call" to a qpy template that calls other qpy
> templates) is built by just building onto one big list. Thus
> returning from a nested qpy template will not do any h8
> concatenation. The return from the "entry call" needs to know to
> concatenate... or maybe not, as the context may deal with it
> happily (e.g. using it as a string will cause the h8 concatenation
> to happen... while still allow to use it explicitly as a list).
>
> - Model qpy templates to be generators... similar concept to above,
> but will affect how the calls are done. Thus the compiled qpy
> template will look like a sequence of yield statements.


I think I remember that at some point long ago,
ptl templates returned TemplateIO instances, which are
basically lists of parts to be concatenated later.  That's more
or less the pattern you are suggesting.  This does, as you
have noted, avoid some extra copying.

It is, however, a more complicated situation for programmers
to understand and use, and, personally, I doubt if the time
required to load a typical page would be improved enough to
compensate for this extra complexity.