Draft PEP: string interpolation with backquotes

[Tim Peters]

[Tim]
>> 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').

[Oren Tirosh]
> The order of prefixes does matter.  Try it.  ur"foo" is valid,
> but ru"foo" isn't.

Woo hoo!  So it is(n't).  I stand humiliated yet enlightened.  I'm a little
disturbed that you knew this, though <wink>.

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

When in Rome ...

> Naturally, the "i" prefix should be case insensitive, just like
> "r" and "u".

Cool.

> ...
> I meant str().  repr() isn't very useful when embedding strings
> because of the quotes.

Bingo.

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

ABC didn't have the str-vs-repr distinction; backtick interpolation was
*the* ABC gimmick, and produced a string the same as ABC's WRITE stmt given
the same expression.  This was like Python's "print" stmt, more str()-like
than repr()-like.  Backtick expressions could nest.

That Python already uses `` for something else remains a hangup,

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

Ack -- support it fully, or not at all.  The user's view of syntactic
complexity derives from the lumpiness of the grammar.