I've worked with "Markup" string type for a few days.  Some new syntax
might be the best way to control how string literals are handled in PTL
modules.  For the application I'm working on (and I suspect for many
others), the literal strings in almost all templates should be
"HTMLMarkup".  We have a few templates that are used for generating
email.  Those need to have normal string literals.

Our PTL modules also contain a fair number of 'def' style functions;
mostly '__init__', 'process', and 'action' methods for forms but also
for other UI related things.  For these functions a normal string
literal is desired.  With the current implementation, the HTMLMarkup
literals can be disabled using _q_markupclass.  For example:

    def __init__(...):
        _q_markupclass = str
        ...

That's ugly.  Having a switch at the syntax level feels like the right
thing.  I propose to use the syntax that Guido is currently considering
for static method declarations.  The syntax would allow three types of
functions in PTL modules.

    def foo(...):
        """This is a normal function like you would find in a
        .py module.  String literals are of type 'str'.
        """
        ...

    def bar [plain] (...):
        """This is a template that behaves like current PTL templates.
        String literals and the return value are of type 'str'.
        """
        ...

    def bar [html] (...):
        """This is a new-style template for generating HTML or XML.
        String literals and the return value are of type 'HTMLMarkup'.
        """
        ...

For backwards compatibility, templates defined using 'template' would
still be accepted.  I'm a little unclear as to what to do about string
literals at global or class level scope.  I think they should be left as
plain 'str' instances.  If we do that, I'm tempted to add the HTMLMarkup
constructor to the global namespace for convenience.  Maybe it could be
called 'html' or 'HTML'.

  Neil