On 08 October 2002, Neil Schemenauer said:
> That's ugly.  Having a switch at the syntax level feels like the right
> thing.

As long as it's at the right level -- I think per-function makes sense.
People putting marked-up strings at module-level will just have to
declare them as such; if they don't, they'll get a very screwed up web
page, which is just fine.

> I propose to use the syntax that Guido is currently considering
> for static method declarations.

I haven't been following python-dev; if this is seriously on the table
for Python 2.3, by all means let's follow that example.  If it's just
"under consideration" but likely to be dropped in the end, I'm a bit
wary of it (although it's still nice syntax).

> 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.

Templates are still quite different from regular functions; I'd prefer
to keep "template" as the primary way way to declare a template.  Maybe
the only way.  I don't think "def" should declare something that has a
very different way of specifying return values from ordinary functions.

(However, this is starting to sound like the how-to-declare-generators
debate leading up to Python 2.2, and "def" won out in the end there.  I
never did make up my mind in that one, mainly because I agreed with the
"but generators *aren't* functions and shouldn't look like them" crowd,
but also appreciate Python's keyword conservatism.  However, we've
already got the "template" keyword in PTL, so we might as well preserve
its primacy.)

IOW, I would favour

  def foo(...):
    define a regular function

  template foo [plain] (...):
    define a template that returns plain (un-marked-up, needs-to-be-
    quoted-if-included-in-HTML) text

  template foo [html] (...):
    define a template that returns HTML text

I prefer "html" to "markup": that way, if it turns out that the right
quoting rules for XHTML or XML or !?%ML are subtly different, we just
extend PTL to recognize a new type of marked-up text.  For now,
everything will just be HTML.

I guess that means I also think the new type should be called either
HTMLString, htmlstr, or HTMLStr.  Or something like that.

> 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'.

+1.  I vote to call it 'htmlstr'.  We go from

  STATIC_TEXT = """\
  
Legal Terms

  blah blah blah ......
  """

to

  STATIC_TEXT = htmlstr("""\
  
Legal Terms

  blah blah blah ......
  """)

which is quite acceptable IMHO.  I could live with 'html' instead of
'htmlstr' too.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org