At 10:23 AM 10/8/02, Neil Schemenauer wrote: >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'. > """ > ... I hope that plain and html are class names, not keywords. Then we would not be limited to three types of functions. For example, one could imagine an sql class that converts strings to the appropriate form for SQL queries. def bar [sql] (lastName): "SELECT * FROM staff\n" "WHERE last = " lastName Calling bar ("O'Henry") produces: SELECT * FROM staff WHERE last = 'O''Henry' The PTL documentation says, "the value is converted to a string using str() and appended to the template's return value. There's a single exception to this rule: None is the only value that's ever ignored, adding nothing to the output." I haven't looked under the hood to see where this is implemented. Is it specific to the current string output, or is it generic to all PTL template processing? In the sql example, it would be better to convert None to SQL's NULL. (But what about function calls that return None by default? Hmmm.) Also, sql could convert date class values to some date format recognized by SQL. -- Joel Shprentz (703) 478-9668 1516 Park Glen Court jshprentz@his.com Reston, VA 20190