Draft PEP: string interpolation with backquotes

[Tim Peters]

[Oren Tirosh]
> PEP: XXXX
> Title: String interpolation with backquotes
> Author: oren at hishome.net (Oren Tirosh)
> Created: 2-Dec-2001

Just a few comments at the start:

> Specification
>
>     A new character prefix "i" is defined for strings.  This prefix
>     precedes the "u" and "r" prefixes, if present.

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

>     and embedded into the string. An empty interpolation ("``") is
>     not allowed.

The Reference Manual already defines the grammar production
string_conversion for what a backtick expression has to look like; just
refer to that; if you attempt to reword it, it will create problems.  Like
this one:

>     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).