Hacker News Reader

Comment by atoav | Hacker News Reader

This is a good PEP. As f-strings were introduced I switched everything except the simplest things to it.

Especially allowing backslash and arbitrary quotes inside the expressions is a welcome and useful change, as this makes f-strings work more as expected without having to remember a lot of special edge cases and work arounds.

View on HN

f-strings are also the fastest way to format a string in Python from what I've seen.

  $ python3.12 -m timeit 'f"Welcome to {2 ** 3}."'
  5000000 loops, best of 5: 69.8 nsec per loop
  $ python3.12 -m timeit '"Welcome to {}.".format(2 ** 3)'
  2000000 loops, best of 5: 112 nsec per loop
  $ python3.12 -m timeit '"Welcome to %d." % 2 ** 3'
  5000000 loops, best of 5: 82.2 nsec per loop
  $ python3.12 -m timeit '"Welcome to " + str(2 ** 3) + "."'
  5000000 loops, best of 5: 77.5 nsec per loop

Surprising that the double concatenation is the second fastest!

Probably because the string is so short.

Yeah, it's not great with long strings. f-strings seem to be great just about always though. Highly recommend.

  $ python3.12 -m timeit -s 'import string' -s 'x = string.printable * 50' 'f"Welcome to {x}."'
  2000000 loops, best of 5: 106 nsec per loop
  $ python3.12 -m timeit -s 'import string' -s 'x = string.printable * 50' '"Welcome to {}.".format(x)'
  2000000 loops, best of 5: 200 nsec per loop
  $ python3.12 -m timeit -s 'import string' -s 'x = string.printable * 50' '"Welcome to %s." % x'
  2000000 loops, best of 5: 169 nsec per loop
  $ python3.12 -m timeit -s 'import string' -s 'x = string.printable * 50' '"Welcome to " + str(x) + "."'
  1000000 loops, best of 5: 214 nsec per loop
  $ python3.12 -m timeit -s 'import string' -s 'x = string.printable * 50' '"Welcome to " + x + "."'
  1000000 loops, best of 5: 198 nsec per loop

len(string.printable * 50) = 5000

TIL. str.format and % parse the format string at runtime, so it's expected that they're slower. But I thought the f-string desugars to something similar to the last one. Turns out it's not, it compiles to specialized opcodes and avoids function calls:

https://bugs.python.org/issue25483

https://bugs.python.org/issue27078

I used to be skeptical, but the great David Beazley convinced me that f-strings rocked because they were faster and better, in his talk "The Fun of Reinvention (Screencast)".

The point he made was to embrace the new features of Python, and put old Python out of its misery, instead of wasting your time with backwards compatibility.

Just call whatever you're doing in the latest version of Python a "prototype", then ship it.

At 10:20 he talks about things you can do to put old Python out of its misery (dead parrot), including f-strings and ordered dictionaries.

The Fun of Reinvention (Screencast):

https://www.youtube.com/watch?v=js_0wjzuMfc

Invited Keynote Talk from PyCon Israel, June 12, 2017. I cause trouble and build a framework using all sorts of new Python 3.6+ features.

> As f-strings were introduced I switched everything except the simplest things to it.

Never really understood why not all strings were f-strings in python.

From the start? I guess because the spirit of Python's syntax is anti-Perl.

Now? Maybe because another breaking change in strings is the worst nightmare of the current generation of Python developers.

Python f-strings are modelled after `string.format`, which is inspired by C# and introduced relatively later. Such interpolated strings would have been much more inconvenient for the older printf-like syntax.

> Never really understood why not all strings were f-strings in python.

Sometimes you don't want interpolation, and it seems more reasonable to default to a version without such a feature than to default to a version with it and have an alternate syntax for non-interpolated strings. Or, at least, that makes sense to me, but I have no knowledge of their motivations.

Because it wouldn't be backwards-compatible.

If Python were designed from scratch today, I suspect it'd do something similar to JS.

Be sude that would make it hell to write strings with literal {}.

I like having different types of strings with different sets of magic characters. Even having identical `'` and `"` strings just to avoid backslashes in a few cases is great.

Yea, Swift really shows how it should be done. One string literal type that can do everything f-strings, r-strings, and """-strings can do and much more.

Logging modules mostly, especially if you have objects that can take a while to serialize to a string, can benefit from the "old" format string approaches. (Percent formatting is for some reason favored, although there's no real good reason to not just use the .format() approach outside of the standard logging library being a dinosaur.)

For conditional formatting (where you don't know if the formatting is needed or the contents of what you're formatting into the string but you know what you want to format), f-strings also lose their use pretty much immediately.

They're great for a quick inline format but less useful for things like string templates you want to use over and over.

Agreed about conditional formatting in current practice, though I wonder how much of it is historical momentum and how Python could have developed if it started with f-strings only. One could use simple functions for replacing string templates if f-strings were the only option.

Reply on news.ycombinator.com