[Python-Dev] PEP-498: Literal String Formatting
Yury Selivanov
yselivanov.ml at gmail.com
Mon Aug 10 17:42:44 CEST 2015
Eric,
On 2015-08-07 9:39 PM, Eric V. Smith wrote:
[..]
> 'f-strings are very awesome!'
>
> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
Congrats for the PEP, it's a cool concept!
Overall I'm +1, because a lot of my own formatting code
looks like this:
'something ... {var1} .. something ... {var2}'.format(
var1=var1, var2=var2)
However, I'm still -1 on a few things.
1. Naming. How about renaming f-strings to i-strings
(short for interpolated, and, maybe, later for i18n-ed)?
So instead of f'...' we will have i'...'.
There is a parallel PEP 501 by Nick Coghlan proposing
integrating translation mechanisms, and I think, that
"i-" prefix would allow us to implement PEP 498 first,
and later build upon it.
And, to my ears, "i-string" sounds way better than
"f-string".
2. I'm still not sold on allowing arbitrary expressions
in strings. There is something about this idea that
conflicts with Python philosophy and its principles.
Supporting arbitrary expressions means that we give a
blessing to shifting parts of application business logic
to string formatting.
I'd hate to see code like this:
print(f'blah blah {self.foobar(spam="ham")!r} blah')
to me it seems completely unreadable, and should be
refactored to
result = self.foobar(spam="ham")
print(f'blah blah {result!r} blah')
The refactored snippet of code is readable even without
advanced syntax highlighting.
Moreover, if we decide to implement Nick's PEP 501, then
supporting expressions in f-strings will cause more harm
than good, as translators usually aren't programmers.
I think that the main reason behind allowing arbitrary
expressions in f-strings is allowing attribute and
item access:
f'{foo.bar} {spam["ham"]}'
If that's the case, then can we just restrict expressions
allowed in f-strings to names, attribute and item lookups?
And if later, there is a strong demand for full expressions,
we can add them in 3.7?
Thanks,
Yury
More information about the Python-Dev
mailing list