4 ms·

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.

by yen223 10y ago

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.
- yen223 10y ago
  Readability absolutely counts - that's precisely the reason why the "one obvious way" rule is there. If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code.
  - orf 10y ago
    > If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code. Sure, which is why .format() kind of sucks. > "Hi {name}, your age is {age}".format(name=name, age=age) You have to parse 'name' and 'age' three times to figure out whats going on. The .format() is completely superfluous in most cases. It's busywork and it's harder to parse. I quite agree with the "one obvious way" to do something, but that should not hinder progress and improvement. f strings are an improvement and are the obvious way to do things, in the same way that '.format' was an improvement over 'str % values', and how 'str % values' is an improvement over manual concatenation. They all still exist, but lets use f strings now and stop complaining?
    - yen223 10y ago
      I'm sorry, but I think you missed my point here. There's now four different ways to do string interpolation, which means that to understand someone else's code, I will need to know how `%`, `.format`, `string.template` and `f` works - I won't know which method the library author uses. I will need to know how they break in edge cases (and they will be broken, otherwise we wouldn't have replaced them!) Worse still, I will also need to know how they interact with each other - you can do something = "abc" x = f"{something}".format(something="def") and I honestly have no idea what x will be. So yeah, I would love to "use f strings and stop complaining", but the fact that the other string interpolation methods still exist, and are still supported, is still going to be a problem.
simonh 10y ago
It's not so much that there is only one way, it's that there's only one best, or right way to do it. If f-strings are better than the ways before, then it becomes the new way to do it, and Python is the better for it.

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.

by 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.

yen223 10y ago
Readability absolutely counts - that's precisely the reason why the "one obvious way" rule is there. If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code.
- orf 10y ago
  > If there's four different ways to something, then that's four different things the reader has to fully understand in order to parse someone else's code. Sure, which is why .format() kind of sucks. > "Hi {name}, your age is {age}".format(name=name, age=age) You have to parse 'name' and 'age' three times to figure out whats going on. The .format() is completely superfluous in most cases. It's busywork and it's harder to parse. I quite agree with the "one obvious way" to do something, but that should not hinder progress and improvement. f strings are an improvement and are the obvious way to do things, in the same way that '.format' was an improvement over 'str % values', and how 'str % values' is an improvement over manual concatenation. They all still exist, but lets use f strings now and stop complaining?
  - yen223 10y ago
    I'm sorry, but I think you missed my point here. There's now four different ways to do string interpolation, which means that to understand someone else's code, I will need to know how `%`, `.format`, `string.template` and `f` works - I won't know which method the library author uses. I will need to know how they break in edge cases (and they will be broken, otherwise we wouldn't have replaced them!) Worse still, I will also need to know how they interact with each other - you can do something = "abc" x = f"{something}".format(something="def") and I honestly have no idea what x will be. So yeah, I would love to "use f strings and stop complaining", but the fact that the other string interpolation methods still exist, and are still supported, is still going to be a problem.

simonh 10y ago

It's not so much that there is only one way, it's that there's only one best, or right way to do it. If f-strings are better than the ways before, then it becomes the new way to do it, and Python is the better for it.