Draft PEP: string interpolation with backquotes

[Oren Tirosh]

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

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

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.

	Oren Tirosh