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

[Raymond Hettinger]

> > * 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