Python 3's F-Strings: An Improved String Formatting Syntax
11–20 of 147 posts
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#12Minor correction: % formatting allows specifying names for dictionary keys too:
In [1]: "%(a)s and %(b)s" % {"a":"A", "b":"B"}
Out[1]: 'A and B'
In fact I had never switched to using str.format as it just never added enough benefit for me over the old %-based formatting.But I do like f-strings and am using them quite a bit. Calling functions or methods inside f-strings is something I had no idea was possible. That is pretty neat:
>>> name = "Eric Idle"
>>> f"{to_lowercase(name)} is funny."
'eric idle is funny.'Re: Python 3's F-Strings: An Improved String Formatting Syntax
#13I can't say I like the f" syntax much. I think JS's backtick is better. Other than that, I agree, much better than % and less verbose than .format. It's just the f" or f' that doesn't sit right with me
(I spent a lot of time thinking about it, and put the idea forward on python-ideas. Though string interpolation is nothing new of course.)
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#14I can't say I like the f" syntax much. I think JS's backtick is better. Other than that, I agree, much better than % and less verbose than .format. It's just the f" or f' that doesn't sit right with me
The main problem with python's f" syntax is that it's just a very complex, non-extensible hack whereas in javascript you can prefix a tag to specify how the interpolation happens.
Instead of this, f-strings have a lot of hardcoded and often broken behavior which can't be fixed let alone customized. For example, you can specify a field width, but it will not even work properly even in a fixed-width context, because of quite common things like emojis or CJK or combining characters don't have their width computed correctly.
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#15> However, once you start using several parameters and longer strings, your code will quickly become much less easily readable [...] `"Hello, %s %s. You are %s. You are a %s ...` Minor correction: % formatting allows specifying names for dictionary keys too: In [1]: "%(a)s and %(b)s" % {"a":"A", "b":"B"} Out[1]: 'A and B' In fact I had never switched to using str.format as it just never added enough benefit for me ov…
f"{name.lower()} is funny."Re: Python 3's F-Strings: An Improved String Formatting Syntax
#16PHP: Am I joke to you?
JFYI meme style responses are frowned upon at HN. That's why you get downvoted.
A much better rephrase of the above would be something along the lines of:
PHP/Javascript/.. also have this feature since ver X. It's main difference/advantage/disadvantage is ...
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#17F-strings have been around for years and this article is at least a few years old. I'm curious why this is coming up now.
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#18 let name = "Bob"
print("Hi my name is \(name)")
Which I always quite liked. I found myself missing this when I moved on to Rust and Go.Re: Python 3's F-Strings: An Improved String Formatting Syntax
#19I can't say I like the f" syntax much. I think JS's backtick is better. Other than that, I agree, much better than % and less verbose than .format. It's just the f" or f' that doesn't sit right with me
I think you are right to prefer JS's backtick notation, but not in your reason. The main problem with python's f" syntax is that it's just a very complex, non-extensible hack whereas in javascript you can prefix a tag to specify how the interpolation happens. Instead of this, f-strings have a lot of hardcoded and often broken behavior which can't be fixed let alone customized. For example, you can specify a field wid…
I'm not sure I expect it to handle every Unicode nuance either, when there are modules in the stdlib for that.
Re: Python 3's F-Strings: An Improved String Formatting Syntax
#20Earlier quoted context omitted.
Yup, especially as you often need to access dict's with foo["field"] and you get a syntax error if the f-strings is also f"". JavaScript backtick syntax doesn't lead to this extra syntactic friction.
You can use any of f"{foo['field']}" f'{foo["field"]}' f"""{foo["field"]}""" (I see from your carefully worded first sentence that you already knew this but still find it annoying, but I'll leave this here for any that aren't aware.)