[Python-Dev] Re: Re: Re: Update PEP 292

[Barry Warsaw]

On Wed, 2004-08-18 at 14:07, Fernando Perez wrote:

> I'd like to argue that this form may be the most useful for common tasks, so
> you can mix and match "this is foo: $foo and this is foo.bar: $foo.bar"
> without having to worry too much about which template class you are using.  

It might be, but using attribute lookup syntax can be problematic.  I
can only relate my experiences with Mailman, where I've been using
something similar for several years, albeit with traditional
%-placeholders.

With attribute placeholders, you typically want the mapping to be
automatically created from the call site's locals and globals, otherwise
you end up having to type many things three times.  That's fine, but
there are gotchas.  First, the exact behavior of the mapping is somewhat
application dependent (do you want locals only, globals and locals, only
some specially named attributes in those namespaces, etc.).  That makes
it difficult to provide a generally useful mapping implementation in the
standard library.  And without a special mapping instance, I think
attribute placeholders are less useful.

Second, you want to be really careful about the context that attributes
are looked up in.  For example, in a CGI context, you can't simply
expose the names of variables that hold data extracted from the form,
otherwise you open yourself up to cross-site scripting attacks.  Then,
as is the case with Mailman, if the template string is really a key into
a translation catalog, you have to be careful that your translators
aren't accidentally or intentionally exposing unsafe objects through
their translated message strings.

So at the very least, I don't think we have enough application
independent use cases to know what kinds of attribute path template
support should go in the standard library.  That may change a year and a
half from now for Python 2.5, but for 2.4 I think it's enough to get the
basic support and interface right, and see what use cases emerge and
become general enough for the standard library.

> How about making a BaseTemplate class which does NOT allow $foo.bar, and having
> the default Template implement attributes?

I'm leery of making this hierarchy too deep.  Really, the only reason
PEP 292's Template and SafeTemplate classes have an inheritance
hierarchy is so that the pattern doesn't have to be written twice. 
Their __mod__()'s are quite different, and other than the pattern and
that method, there ain't much to those classes.

> Best, and thanks for keeping an open mind about this issue (string
> interpolation is one of the very few areas where python's syntax bugs me, even
> after years of daily use).

And thank you for your suggestions.  Hopefully by Python 2.5 time frame
we'll have enough experience with this stuff to be able to extend them
with other useful classes.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20040822/6808d0ad/attachment.pgp