Draft PEP: string interpolation with backquotes
oren-py-l at hishome.net
Sun Dec 2 23:08:05 CET 2001
On Sun, Dec 02, 2001 at 02:44:22PM -0500, Tim Peters wrote:
> Seems overspecified: "U" and "R" are also legit prefixes, so "I" should be
> too. The order of prefixes shouldn't matter (just as it doesn't matter now
> for mixing 'u'/'U' and 'r'/'R').
The order of prefixes does matter. Try it. ur"foo" is valid, but ru"foo"
isn't. I don't know the original rationale for this decision but I tried
to keep it. Do you have any special arguments one way or the other?
Naturally, the "i" prefix should be case insensitive, just like "r" and "u".
> > The prefix "i" stands for "interpolation" or "in-line". Within
> > a string with an "i" prefix an expression enclosed in backquotes is
> > converted into its string representation
> That's ambiguous, and this is a real problem: Python generally has two
> forms of "string representation", str() and repr(). Unfortunately for the
> proposal, backticks are a shortcut for repr() but str() is probably more
> useful in this context.
I meant str(). repr() isn't very useful when embedding strings because of
the quotes. I should have been more specific. Yes, this is inconsistent
with the standard use of backquotes which is equivalent to repr(), not
str(). I believe this is an acceptable compromise since it does the
Right Thing for formatting. I wonder how ABC's backquotes worked inside
> > The expression may be any valid Python expression not containing
> > the backquote character.
> This is an unnecessary difference with current backtick expressions. It's
> not particularly pretty to look at, but nested backtick expressions are
> unambiguous and work fine. Artificially restricting them in this context
> would be a wart (not to mention that you couldn't reuse the compiler code
> that compiles them now).
I am aware of this. The reason for this restriction is simplicity. String
interpolation is meant for short expressions, often just a single name.
In my proposed implementation most of the processing occurs at the tokenizer
while parsing nested backtick expressions unambigously is a job for the
parser so this keeps the implementation simple. A possible approach I have
considered is to allow nested backticks inside interpolations as long as
they are surrounded by at least one level of parens/braces etc. The
tokenizer already counts paren levels for expressions extending across
I consider the fact that interpolation is done very early, starting at the
tokenizer level to be the most important feature of this proposal. It's
good that Python has an eval() function but overuse of runtime evaluation
is one of the first steps on the road to scripting language hell :-)
A late-binding string interpolation system is a form of functional
programming implemented with runtime evaluation. No thanks, we already
have lambda functions for that.
More information about the Python-list