5 ms·

Surprisingly these are very controversial. A bunch of people seem to hate them. I don't understand why.

masklinn 10y ago
I dislike them because not only are they one more string-formatting method (they're similar to but not actually identical to format-strings as you can use arbitrary expressions in f-string placeholders) and more importantly they're the first one which does not work at all for i18n or more generally for deferred interpolation (which is also used by `logging`)
- orf 10y ago
  > importantly they're the first one which does not work at all for i18n But surely i18n/deferred interpolation is a corner case, not the norm. If you need that then use what you are currently using, nothings changed.
- JelteF 10y ago
  Not sure, why you think they cannot be used with defered interpolation. You, can easily combine the two like this: >>> f'{"fstring"} and {{deferred}}'.format(deferred=1234) 'fstring and 1234'
- mixmastamyk 10y ago
  There was a large attempt to get i18n/deferred but Guido decided to keep it simple for this release. Perhaps it can be extended in the future. In the meantime i18n uses string.Template.
yen223 10y ago
There are already three ways to do string interpolation. Adding a fourth way goes against the whole "only one way to do things" aspect of the Zen of Python.
- JelteF 10y ago
  The "only one way to do things" is quite low in the Zen of python. It is preceded by for instance "Beautiful is beter than ugly", "Readability counts" and "practicality beats purity" [1]. There's always a trade of in these rules. In this case I think the right choice was made to add this easier way of doing string interpolation for cases where it can be used, also "Now is better than never". [1] Python 3.5.2 (default, Nov 7 2016, 11:31:36) [GCC 6.2.1 20160830] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>>
  - wyldfire 10y ago
    I didn't know that it was a ranking. I'm disappointed that there's so many ways to do string formatting/templating, but I think we're all so very painfully aware of how important backward compatibility is. So for the language to gain features like this, I think it should be understood that it will also keep the old ways.
- orf 10y ago
  There are several ways of doing multiplication and division (statements, math library, a loop). Should we enforce only one? No. Readability counts. One (and only one) point from the Zen of Python does not make an argument against it.
  - 10y ago

I dislike them because not only are they one more string-formatting method (they're similar to but not actually identical to format-strings as you can use arbitrary expressions in f-string placeholders) and more importantly they're the first one which does not work at all for i18n or more generally for deferred interpolation (which is also used by `logging`)

orf 10y ago
> importantly they're the first one which does not work at all for i18n But surely i18n/deferred interpolation is a corner case, not the norm. If you need that then use what you are currently using, nothings changed.
JelteF 10y ago
Not sure, why you think they cannot be used with defered interpolation. You, can easily combine the two like this: >>> f'{"fstring"} and {{deferred}}'.format(deferred=1234) 'fstring and 1234'
mixmastamyk 10y ago
There was a large attempt to get i18n/deferred but Guido decided to keep it simple for this release. Perhaps it can be extended in the future. In the meantime i18n uses string.Template.

yen223 10y ago

There are already three ways to do string interpolation. Adding a fourth way goes against the whole "only one way to do things" aspect of the Zen of Python.

JelteF 10y ago
The "only one way to do things" is quite low in the Zen of python. It is preceded by for instance "Beautiful is beter than ugly", "Readability counts" and "practicality beats purity" [1]. There's always a trade of in these rules. In this case I think the right choice was made to add this easier way of doing string interpolation for cases where it can be used, also "Now is better than never". [1] Python 3.5.2 (default, Nov 7 2016, 11:31:36) [GCC 6.2.1 20160830] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>>
- wyldfire 10y ago
  I didn't know that it was a ranking. I'm disappointed that there's so many ways to do string formatting/templating, but I think we're all so very painfully aware of how important backward compatibility is. So for the language to gain features like this, I think it should be understood that it will also keep the old ways.
orf 10y ago
There are several ways of doing multiplication and division (statements, math library, a loop). Should we enforce only one? No. Readability counts. One (and only one) point from the Zen of Python does not make an argument against it.
- 10y ago