4 ms·

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 ins

• Affric 3y ago
  > 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.
  • lifthrasiir 3y ago
    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.
  • owl57 3y ago
    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.
  • DonaldPShimoda 3y ago
    > 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.
  • int_19h 3y ago
    Because it wouldn't be backwards-compatible. If Python were designed from scratch today, I suspect it'd do something similar to JS.
  • mFixman 3y ago
    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.
  • boxed 3y ago
    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.
  • noirscape 3y ago
    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.
    • pama 3y ago
      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.
• Hamuko 3y ago
  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
  • elevatedastalt 3y ago
    Surprising that the double concatenation is the second fastest!
    • L3viathan 3y ago
      Probably because the string is so short.
      • Hamuko 3y ago
        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
  • owl57 3y ago
    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/issue25483 https://bugs.python.org/issue27078 https://bugs.python.org/issue27078