4 ms·
It's difficult to balance it out correctly. F-strings were a significant improvement and I still think it was a great idea to include them and trade off some o
by superbcarrot 6y ago
It's difficult to balance it out correctly. F-strings were a significant improvement and I still think it was a great idea to include them and trade off some of the language simplicty for the added convenience. This new pattern matching... I'm not convinced yet.
- roelschroeven 6y agoPersonally I don't feel f-strings are an improvement at all, but I think I can see why people prefer them. But a significant improvement, that I don't see at all. Can someone explain why e.g. f'gcd({a}, {b}) = {math.gcd(a, b)}' is so much better than 'gcd({}, {}) = {}'.format(a, b, math.gcd(a, b)) In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. I really like that separation. When the expressions get more complex, .format() doesn't really lose any clarity while f'' gets pretty unreadable quite fast IMO. Yes, you can simplify by assigning the expressions to variables, but .format() doesn't even need that.
- superbcarrot 6y agoI find the f-string version better because I read from left to right and find it unnatural when my eyes need to jump around several times over the same expression in order to parse it. In your example that effect isn't too strong because there isn't a lot of additional text in the string and it's very clear what's going on either way.
- IanCal 6y ago> In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. It makes it harder to see which values actually go where though. I really dislike the separation.
- ju_sh 6y agoThank goodness we still have both ;)
- roelschroeven 6y ago> I really dislike the separation. That's obviously a pretty fundamental difference in point-of-view. And it looks like your point-of-view is shared by a large majority. "The reasonable man adapts himself to the world. The unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw I try to be reasonable, so I guess I should try to come to terms with f-strings. In any case please don't depend on more progress.
- thaumasiotes 6y ago> It makes it harder to see which values actually go where though. You can name the variables in the format string and then pass the expressions as keyword parameters.
- aidos 6y agoYou can do that with f-strings too... but you don't need to because they're generally already clearer.
- cjohnson318 6y agoOnce you get over five arguments in str.format(), it gets weird. I reverse engineered a product that required a lot of string formatting, and f strings made things more readable and debuggable.
- nuclear_eclipse 6y agoJust wait until you get Python 3.9 and can do: >>> a, b = 2, 4 >>> f"{math.gcd(a, b) = }" 'math.gcd(a, b) = 2'
- contravariant 6y agoSometimes you just want to quote something in a string real quick. In some cases you want to do something slightly more complicated. And I really dislike format where the arguments are given by position. For short strings it's not going to matter but for long strings you're bound to mess something up sometime. Just imagine writing some kind of long email template and ending up with something like: '''Dear {}{} I write you on the {} to inform you... Kind Regards, {}'''.format('Mr. ', 'President', '1st of April', 'Ohio', '12', ..., 'Automated mail bot') Okay it's a bit contrived but any long multiline formatted string is going to be hard to read without using keywords. And once you insist things are named then f-strings look a lot neater since you get: f'gcd({a}, {b}) = {math.gcd(a, b)}' v.s. f'gcd({a}, {b}) = {gcd_a_b}'.format(a=a,b=b,gcd_a_b=math.gcd(a, b)) Of course sometimes a template is the appropriate tool, but usually because it's going to be used more than once.
- mixmastamyk 6y agoThe first is more readable and performant, the second is much more error prone. One of the things folks complain about in Python is runtime errors, this is one part of the solution. Is that enough?
- roelschroeven 6y agoI don't know about performant. If the difference is significant, that can be something to take into account, depending on the situation. Otherwise readability is more important. So we come to readability, and I have to say that to me .format() is more readable. Honestly. Regarding runtime errors, I presume you mean .format() doesn't prevent mismatches between the number of placeholders and the number of arguments, as in '{} {}'.format(42)? That's indeed a point in favor of f'', that I hadn't previously considered.
- mixmastamyk 6y agoThe eff string uses a special instruction that makes it not need to do expensive function lookups at runtime. These are costly in Python. Better in loops. Readability is a win in my book. You mention too much is happening in your example string. Ok, perhaps it is. But remember, just because the interpolation supports expressions, doesn't mean you have to put them in there. I'd argue your function call would be better done on the line above, with only the result put in the string. This is the most readable version so far I think: c = math.gcd(a, b) f'gcd({a}, {b}) = {c}' Syntax highlighting helps out as well. Yes about placehoders. Also that in some cases of format() each variable is repeated a number of times: 'hello {name}'.format(name=name) When this is changed it is a bug magnet. DRY in a nutshell. Rarely is a feature a home run like this one. Not to mention I was using it in batch files, shells, and perl twenty-five years ago.
- marcinzm 6y agoAs I see it the less cognitive overhead I have when reading code the better. The more I have to think about the code I am reading the more likely I am to make a mistake because my brain is not a machine. With f" I simply read the code left and right and understand the output as I go. When I see the output I'm interested in I stop and see the context instantly. With .format() I read left and right, stop once I get to what I'm interested in, go back to count the {}s, remember the count, and finally count the arguments. Multiple places to make a mistake. And doing this when refactoring code is how you get bugs.
- scarygliders 6y agoThank you! Like you - and I just learned about the existence of f-strings tonight - I find .format() to be much more readable and logical than f-strings. My first impression reading about f-strings was "ew." It's not a case of "I don't like it because it's new". To my jaundiced and admittedly subjective eyes, I'm still finding .format() better, precisely because it doesn't lose any clarity in exactly the way you stated. In other words, I just don't get the point. Furthermore! f? Really? What the f does f mean? The str() function is the str() function. As well as print(). As well as .format(). f? please