[Python-ideas] String interpolation for all literal strings

[Nick Coghlan]

On 6 August 2015 at 14:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I'm in this camp as well. We already suffer from the problem that,
> unlike tuples, numbers and strings, lists, dictionary and set
> "literals" are actually formally displays that provide a shorthand for
> runtime procedural code, rather than literals that can potentially be
> fully resolved at compile time.

Sorry, I had tuples in the wrong category there - they're their own
unique snowflake, with a literal for the empty tuple, and an n-ary
operator for larger tuples.

The types with actual syntactic literals are strings, bytes, integers,
floats and complex numbers (with an implied zero real component):
https://docs.python.org/3/reference/lexical_analysis.html#literals

The types with procedural displays are lists, sets, and dictionaries:
https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries

One of the key things I'll personally be looking for with Eric's PEP
are the proposed changes to the lexical analysis and expressions
section of the language reference.

With either f-strings or bang-strings (my suggested alternate colour
for the bikeshed, which is exactly the same as f-strings, but would
use "!" as the prefix instead of "f" to more clearly emphasise the
distinction from the subtle effects of "u", "b" and "r"), those
changes will be relatively straightforward - it will go in as a new
kind of expression.

If the proposal is to allow arbitrary code execution inside *any*
string, then everything except raw strings will need to be moved out
of the literals section and into the expressions section. That's a
*lot* of churn in the language definition just to save typing one
prefix character to explicitly request string interpolation.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia