[Zope-dev] Python Methods commited

Phillip J. Eby pje@telecommunity.com
Fri, 17 Dec 1999 18:11:02 -0500


At 03:52 PM 12/17/99 -0500, Christopher Petrilli wrote:
>
>>> * Access to things like the formatters via "magic namespace"
>> 
>> There have been several times when I've wanted access to these in
*DTML*, much
>> less PMs, as in:
>> <dtml-call expr="REQUEST.set('foo',
>> ??how_do_I_call_a_special_format??(the_text_to_format))">

This is perhaps more appropriate for DTML than for PythonMethods, but here
is a possible proposal...

Make the __call__ method of the "_" object look for a positional parameter.
 If present, format it using the formats specified by the keyword
parameters, and return the result.  Thus:

<dtml-var expr="_(thingToFormat, html_quote=1, newline_to_br=1)">

Would be equivalent to:

<dtml-var thingToFormat html_quote newline_to_br>

If PythonMethods were able to either use the standard "_" object (when
passed in by a DocumentTemplate), or use "import _" to get a fresh "_"
object otherwise, then matters would be covered either way.

The main objection I see to this is that it's mingling two totally
different uses of _().  Of course, the usual use of _() is not relevant to
PythonMethods, but it is in DTML if you prefer not to use "let".  The
objection could be perhaps be mitigated by deprecating the old use of _()
in favor of dtml-let, but then given the recent let/local/set discussion,
perhaps that's not a good idea.  Sigh.

Now that PythonMethods are in the Zope CVS, I may take a whack this weekend
at adding another option to them, if other people don't find it offensive
(and perhaps even if they do... ;) ).  ASP syntax.  That is:

<% if foo>1: %>
The value of foo is <%= foo %>.
<% else: %>
Foo isn't worth much.
<% end if %>

I already have a robust ASP->Python translator I've had in production use
for years, so incorporating it into PythonMethods should be just a matter
of adding a syntax option, and a call to the translator at just the right
moment.  The translator makes up for the infamous ASP whitespace problem by
implementing block end syntax (end if, end for, end while, end def, etc.).

Anyway, with this syntax, and the "_" proposal the previous formatting
example could be rendered:

<%= _(thingToFormat, html_quote=1, newline_to_br=1) %>

And, what's more, this:

<%= _(id) %>

Would give you back either id or id() depending on whether id was callable.
 Voila, PythonMethods would now be able to do anything that core DTML can,
but with a consistent syntax and without hidden conversions.  And that
includes generating HTML.

One of the nifty things about ASP syntax is that a lot of off-the-shelf
editing tools support it, or at least don't choke on it.  What's also nice
about it, is that people who have ASP experience can leverage their
understanding to a greater extent than they can with DTML.  Python is a lot
like what VBScript ought to have been.  :)