[Python-Dev] Alternative Implementation for PEP 292: SimpleString Substitutions

Raymond Hettinger python at rcn.com
Mon Aug 30 07:48:46 CEST 2004


[Raymond]
> > One negative effect of the class implementation is that it inherits
from
> > unicode and always returns a unicode result even if all of the
inputs
> > (mapping values and template) are regular strings

[Barry]
> To me that's not a disadvantage.

By not inheriting from unicode, the bug can be fixed while retaining a
class implementation (see sandbox\curry292.py for an example).

But, be clear, it *is* a bug.

If all the inputs are strings, Unicode should not magically appear.  See
all the other string methods as an example.  Someday, all will be
Unicode, until then, some apps choose to remain Unicode free.  Also,
there is a build option to not even compile Unicode support -- it would
be a bummer to have the $ templates fail as a result.


Raymond 


P.S.  Here's the doctest from the sandbox code.  What is at issue is the
result of the first test:

>>> Template('the $xxx and')(xxx='10')
'the 10 and'
>>> Template(u'the $xxx and')(xxx='10')
u'the 10 and'
>>> Template('the $xxx and')(xxx=u'10')
u'the 10 and'
>>> Template(u'the $xxx and')(xxx=u'10')
u'the 10 and'






More information about the Python-Dev mailing list