31–40 of 147 posts
I 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
It's consistent with other strings in Python like r-strings and the older u-strings.
This is super minor but I really wish f-string formatting were the default behavior for `print` or that there were a `printf` command just for it. Typing that extra f character before the quotes is just annoying enough
It was a beautiful thing and made it possible to write the same "hello world" program in Python and BASIC:
print "hello, world"This is super minor but I really wish f-string formatting were the default behavior for `print` or that there were a `printf` command just for it. Typing that extra f character before the quotes is just annoying enough
This reminds me of Swift's string formatting syntax: 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.
Squiggly heredoc is something I am unaware of in any other general programming language.
The thing which annoys me most about f strings is I can't build them at runtime, which means I can't just learn/teach f strings. While I know why building f strings is forbidden (they can run arbitrary code), I'm happy to take the risk.
Not mentioned in the article, but with Python 3.8, f-strings have gained the ability to print debug information using `=` specifier. name = 'world' print(f'hello {name.upper()=}') outputs: hello name.upper()='WORLD' It's small, but very useful in debugging an issue or logging something to the console. https://docs.python.org/3/whatsnew/3.8.html#f-strings-suppor...
This reminds me of Swift's string formatting syntax: 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.
Which is usually used for escaping characters. Like, \n for new line.
So, you may end up with code like:
print(“Hi. \nMy name is \(name).”)I 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
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.
Since this:
"this is a "regular" string"
isn't valid, then neither is this:
f"dict lookup: {d["key"]}"
However, we've talked about changing f-string parsing from a "post-process regular strings" mode, to instead having the tokenizer and parser themselves aware of f-strings. When we do that, the f-string example above will work.
(edit for formatting)
I 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
Then you could drop the "f" prefix. I also propose adding a "p" prefix (for "plain") to remove the f-string parsing behavior.
I talked about it at the last Python core sprint, and it only got lukewarm support, so I'm not sure I'm going to pursue it.