[Python-Dev] PEP-498: Literal String Formatting

[Eric V. Smith]

On 08/10/2015 01:26 PM, Steven D'Aprano wrote:
> On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote:
> 
>> Which brought to mind a certain thought.  While I don't like:
>>
>>     f'My name is {name}, my age next year is {age+1}'
>>
>> I wouldn't have any similar objection to:
>>
>>    'My name is {name}, my age next year is {age+1}'.scope_format()
>>
>> Or
>>
>>   scope_format('My name is {name}, my age next year is {age+1}')
>>
>> I realize that these could be completely semantically equivalent... but the
>> function or method call LOOKS LIKE a runtime operation, while a one letter
>> prefix just doesn't look like that (especially to beginners whom I might
>> teach).
> 
> I fear that this is actually worse than the f-string concept. f-strings, 
> as far as I understand, are literals. (Well, not exactly literals.) You 
> cannot say:
> 
>     # this can't happen (I think?)
>     expr = 'age + 1'
>     result = f'blah blah blah {' + expr + '}'
> 
> and inject the expression into the f-string. That makes them a little 
> weaker than eval(), and hence a little safer. 

Correct. f-strings only work on literals. They essentially convert the
f-string literal into an expression (which is not strictly specified in
the PEP, but it has examples).

> But scope_format would
> have to be eval in disguise, since it receives a string as argument, 
> and it can't know where it came from or how it came to be:
> 
>     # pretend that expr comes from, say, a web form
>     expr = 'age + 1}{os.system("echo Pwned!") and ""'
>     result = scope_format(
>         'My name is {name}, my age next year is {' + expr + '}'
>         )
> 
> It's a dilemma, because I'm completely with you in your discomfort in 
> having something which looks like a string literal actually be a 
> function of sorts; but turning it into an actual function makes it more 
> dangerous, not less.
> 
> I think I would be happy with f-strings, or perhaps i-strings if we use 
> Nick's ideas about internationalisation, and limit what they can 
> evaluate to name lookups, attribute lookups, and indexing, just like 
> format().
> 
> We can always relax that restriction in the future, if necessary, but 
> it's a lot harder to tighten it.

This desire, which many people have expressed, is not completely lost on me.

Eric.