101–110 of 147 posts
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...
Earlier quoted context omitted.
As the sibling comment points out, it actually doesn't work that way. The first parameter is only treated as a format string _if_ there are arguments. If not, it is treated as a literal string: https://github.com/python/cpython/blob/dcea78ff53d02733ac598...
I stand corrected. Thanks. (That's what I get for assuming consistent behavior :P)
F-strings are great. The only downside I’ve found is they are incompatible with the stdlib logging framework’s deferred string interpolation feature (using %s style string interpolation), which can give you a nice performance boost if you make lots of expensive debug logs for tests, but run at info level in production. That said most apps probably won’t see much of a difference in perf between the two approaches.
I found out about f strings from an HN comment a few years ago. Ever since I have been super excited to show people who don't know about them. In Python 2 I used to use .format(**locals()) which is basically the same thing, but felt like a hack.
A wart is the standard logging module, which uses %-style strings. For example: log.debug("Unexpected, got %r", (got,)) By doing it this way, it can defer rendering the string until it is actually needed, which is (assumed to be) a win when the logging module is normally just going to toss the low level messages away rather than emit them anywhere. I think you lose this optimization if you use f-strings. I don't thin…
Even if logging can't use f-strings, is there a reason it can't use `string.format`? Limiting logging to `%`-formatting seems to be an inconsistency similar to supporting `%` but not `format` on `bytes` and `bytearray`.
the logging module predates the `.format` function.
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
And while they're at it, bring back the print statement. It was a beautiful thing and made it possible to write the same "hello world" program in Python and BASIC: print "hello, world"
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.
I mean it's Python, so you can do anything: >>> fstring="Hello, {\"world\"}" >>> eval(f"print(f'{fstring}')") Hello, world
Earlier quoted context omitted.
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…
> Instead of this, f-strings have a lot of hardcoded and often broken behavior which can't be fixed let alone customized They are customizable on an object-to-be-formatted basis (__format__ special method).
f"Article: {fixformatting(somestr):20} Price: {fixformatting(price):5.3}"
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.
Doesn't calling .format on a string do the exact same thing as an f-string?