> A pretty simple change to the qpy compiler makes it easy
> to support an alternative, decorator-like notation that
> looks like this:
>
> @[html]
> def f():
>     pass
>
> @[str]
> def g():
>     pass

I don't mind this at all; responding to the follow up conversation,
@[xml] sounds good and a side effect of the name change might make
it easier to spot mistakes while migrating. +1

Do you envision any changes that would enable the use of docstrings
in @[xml] functions and methods? I don't find the current situation
troubling at all - if I feel compelled to have a docstring, I will
occasionally do something like this (in the proposed style):

def format_children(kids, max_foo):
    """(kids : Children, mag_foo : int) -> h8

    Blah..
    """
    @[xml]
    def format():
        for kid in kids:
            kid.format()
            if key.get_foo() > max_foo:
                ' %s' % kid.get_foo()
            else:
                kid.get_foo()


I wonder if @[string] (or some other non reserved word - @[text] ? -
would be less confusing than str or plain? Then again, [plain] isn't
sprinkled very much through my code so changing that to
@[foobazfrump] wouldn't be a big chore either.

I seem to recall my early days with Quixote being somewhat puzzled
by html and plain but can't remember why that was.

@[xml] | @[str]
@[xml] | @[string]
@[xml] | @[text]
@[quoted] | @[passthrough]
@[quotesafe] | @[passthrough]
@[magicbus] | @[sober]

Oops.

As I think about this, there is some danger in implying too much by
way of name.

> Note that both notations are syntax errors for the ordinary
> Python compiler, and this is essential, since it would be
> very bad to have templates accidentally compiled with the
> wrong compiler.

I'm also in favour of retaining the specific extension for such
files. In addition to keeping things explicit, I believe the .qpy
extension requirement helps gently encourage (my first choice of
words, enforce, is too strong a word) separating UI from objects. It
also makes it easy to find stuff on a file system, regardless of
whether one has lumped everything into one package or not.

Re new audiences, discussion continues within other web framework
communities on issues like XSS protection (which Quixote and QP have
enjoyed for so long) and Unicode (thank you QP) -- I wish they'd
look at QPY. They might not agree with __all__ of the design
decisions (decorator format and file extensions/integration with the
compiler) but perhaps could take advantage of QPY in a way that
pleases them none the less.

The same comment goes to template makers too; in the summer I built
a toy qpy-based template system, only after having looked briefly at
Mako and stopped early on by its inability (at that time) to deal
with h8 instances. When I have more time I'll revisit and see if the
issue was due to ignorance or an error on my part or something more
systemic.