
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