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

Raymond Hettinger python at rcn.com
Fri Aug 27 19:37:11 CEST 2004

> * doesn't force result to unicode

[Aahz]

This is the main reason I'm +0, pending further arguments.

Employing class logic for a function problem is my main reason. Any function can be wrapped in class logic and use an overloaded operator (string.template for example) -- it's invariably the wrong thing to do for reasons of complexity, separation of instantiation and application, and the issues that always arise when an operator is overloaded (a good technique that should only be applied sparingly).

[Aahz]

OTOH, I also like using %, so you'd have to come up with more points to move me beyond +0.

The reasons center around the remoteness of instantiation from application, the differences from current uses of %, and an issue with the % operator itself.

When application is remote from instantiation (for instance, when a template argument is supplied to a function), we get several problems. Given a line like "r = t % m", it is hard to verify that the code is correct. Should there be KeyError trapping? Can m be a tuple? Is t a %template, a safetemplate, or dollartemplate? Is the result a str or Unicode object? Should the decision of safe vs regular substitution be made at the point of instantiation or application?

The temptation will be to reuse existing code that uses the % operator which unfortunately is not the same (especially with respect to applying tuples, return types, and auto-stringizing). The % operator is hard to search for in the docs and has precedence issues arising from its primary use for modulo arithemetic. Also, using a function makes it possible to use both % formatting and $ formatting (I do have use a case for this). Further, the % operator mnemonically only makes sense with % identifier tags -- it makes less sense with $ tags.

Whatever answer is chosen, it should be forward looking and consider that others will want to add functionality (local namespace lookups for example) and that some poor bastards are going to waste time figuring out how to subclass the current implementation. In time, there will likely be more than two of these -- do you want more classes or more functions?

Raymond

More information about the Python-Dev mailing list