[Python-Dev] Re: Re: Re: Update PEP 292 (original) (raw)

Barry Warsaw barry at python.org
Sun Aug 22 21:17:21 CEST 2004

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: fooandthisisfoo.bar:foo and this is foo.bar: fooandthisisfoo.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

More information about the Python-Dev mailing list