[Python-ideas] Simplifying .format() based string interpolation

[spir]

On 02/07/2014 02:46 AM, Chris Angelico wrote:
> On Fri, Feb 7, 2014 at 12:24 PM, Robert Hölzl <robert.hoelzl at posteo.de> wrote:
>> mmh; why magical?
>>   - it is explicit (the string is marked by 'f')
>>   - it is side effect free
>>   - does not change the behaviour of an existing feature
>
> It looks like a new form of literal, but it's actually a run-time
> expression evaluator. All the other types of string literal produce,
> ultimately, the same thing: a string. (Okay, the u"" and b"" prefixes
> choose between one of two things, but you still simply get one single
> literal object.) There's no such thing as a "raw string" or a
> "multi-line string"; there's just a "raw string literal" and a
> "multi-line string literal".
>
>>>> r"asdf\qwer" == """asdf\\qwer"""
> True
>
> But now, what you're suggesting is that f"some string" is a thing that
> does interpolation. You have something that looks like a literal, but
> whose value depends majorly on context. No other form of literal is
> like that, unless you count the way [a,b,c] will depend on the values
> of a, b, and c - and that's not so much a literal as a piece of syntax
> that constructs something, as can be seen in dis.dis:
>
>>>> def foo(x):
> a = "string literal"
> b = r"raw string literal"
> c = ["list","literal"]
> d = [a,b,c]
> return d
>
>>>> dis.dis(foo)
>    2           0 LOAD_CONST               1 ('string literal')
>                3 STORE_FAST               1 (a)
>
>    3           6 LOAD_CONST               2 ('raw string literal')
>                9 STORE_FAST               2 (b)
>
>    4          12 LOAD_CONST               3 ('list')
>               15 LOAD_CONST               4 ('literal')
>               18 BUILD_LIST               2
>               21 STORE_FAST               3 (c)
>
>    5          24 LOAD_FAST                1 (a)
>               27 LOAD_FAST                2 (b)
>               30 LOAD_FAST                3 (c)
>               33 BUILD_LIST               3
>               36 STORE_FAST               4 (d)
>
>    6          39 LOAD_FAST                4 (d)
>               42 RETURN_VALUE
>
> Technically there's no "list literal" syntax, only a convenient form
> for constructing a list at run-time. What you're doing here looks like
> a string literal, but isn't a literal at all.
>
> (Note that tuples do kinda have a literal syntax. If you replace the
> square brackets with round ones, you'll find that the all-literals
> tuple gets stored as a const, same as the strings are. But that's an
> optimization that works only when everything's literals, which - kinda
> by definition - your f'' string won't be.)

Well, in fact all your argumentation just supports the proposal, doesn't it? 
There would be string constants and string variables:
	"Hello, world!"
	"Hello, {username}!"
just like list constants and list variables:
	[1,2,3]
	[a,b,c]

So, where's the *actual* problem? It's not as if it were implicit or otherwise 
hidden. And we would not even need an 'f' prefix if it were not for backward 
compatibility (or maybe the parser could deal with that?); various languages 
just use this format (among others, Cobra, highly influenced by Python) and have 
just abandoned all this complicated variable string syntax noise. Would be very 
pythonic, in my view (but maybe I don't get what pythonic means for this matter; 
but surely it does not mean unneeded complication).

d