[Python-Dev] Alternative Implementation for PEP 292: SimpleString Substitutions (original) (raw)

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