[Python-Dev] Re: Alternative Implementation for PEP292:SimpleString Substitutions

Barry Warsaw barry at python.org
Fri Sep 10 04:43:55 CEST 2004


On Wed, 2004-09-08 at 11:08, Guido van Rossum wrote:
> > Templates are meant to template *text* data, so Unicode is
> > the right choice of baseclass from a design perspective.
> 
> Only in Python 3.0.
> 
> But even so, deriving from Unicode (or str) means the template class
> inherits a lot of unwanted operations.

Except that I think in general it'll just be very convenient for
Templates to /be/ unicodes.

But no matter.  It seems like if we make Template a simple class, it
will be possible for applications to mix in Template and unicode if they
want.  E.g. class UTemplate(Template, unicode).

If we go that route, then I agree we probably don't want to use
__mod__(), but I'm not too crazy about using __call__().  "Calling a
template" just seems weird to me.  Besides, extrapolating, I don't think
we need separate Template and SafeTemplate classes.  A single Template
class can have both safe and non-safe substitution methods.

So, I have working code that integrates these changes, and also uses
Tim's metaclass idea to provide a nice, easy-to-document pattern
overloading mechanism.  I chose methods substitute() and
safe_substitute() because, er, that's what they do, and those names also
don't interfere with existing str or unicode methods.

And to make effbot and Raymond happy, it won't auto-promote to unicode
if everything's an 8bit string.

I will check this in and hopefully this will put the issue to bed. 
There will be updated unit tests, and I will update the documentation
and the PEP as appropriate -- if we've reached agreement on it.

-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/20040909/27bcbd95/attachment-0001.pgp


More information about the Python-Dev mailing list