[Python-Dev] Utopian String Interpolation

Paul Prescod paul@prescod.net
Tue, 15 Jan 2002 09:43:56 -0800


I think that if we're going to do string interpolation we might as go
all of the way and have one unified string interpolation model.

 1. There should be no string-prefix. Instead the string \$ should be
magical in all non-raw literal strings as \x, \n etc. are. (if you want
to do string interpolation on a raw string, you could do it using the
method version below)

>>> from __future__ import string_interp

>>> a = "acos(.5) = \$(acos(.5))"

Embrace the __future__!

 2. There should be a transition period where literal strings containing
"\$" are flagged. This is likely rare but may occur here and there. And
by the way, unused \-sequences should probably be proactively reserved
now instead of silently "failing" as they do today. What's the use of
making "\" special if sometimes it isn't special?

 3. I think that it would be clearest if any expression other than a
simple variable name required "\$(parens.around.it())". But that's a
minor decision.

 4. Between the $-sign and the opening paren, it should be possible to
put a C-style formatting specification. 

"pi = \$5.3f(math.pi)". 

There is no reason to force people to switch to a totally different
language feature to get that functionality. I never use it myself but
presume that scientists do!

 5. The interpolation functionality is useful enough to be available for
use on runtime-generated strings. But at runtime it should have a
totally different syntax. Now that Python has string methods it is clear
that "%" could (and IMO should) have been implemented that way:

newstr = mystr.interp(variabledict, evaluate_expressions=0)

By default evaluate_expressions is turned off. That means that all it
does is look up variables in the dictionary and insert them into the
string where it seems \$. If you want full interpretation behaviour you
would flip the evaluate_expressions switch. May Guido have mercy on your
soul.

 6. People should be discouraged from using the "%" version. Some day
far in the future it could be officially deprecated. We'll tell our
children stories about the days when we modulo'd strings, tuples and
dictionaries in weird and wonderful ways.

Once the (admittedly long) transition period is over, we would simply
have a better way to do everything we can do today. Code using the new
model will be easier to read, more concise, more consistent, more like
other scripting languages, abuse syntax less and use fewer logical
concepts. Arguably, functions like vars(), locals() and globals() could
be relegated to an "introspection" module where no newbie will ever look
at them again. (okay, now I'm over-reaching)

There will undoubtedly be language-change backlash. Guido will take the
heat, not me. He would have to decide if it was worth the pain. I think,
however, that the resulting language would be an improvement for experts
and newbies alike. And as with other changes -- sooner is better than
later. The year after next year is going to be the Year of Python so
let's get our changes in before then!

 Paul Prescod