f-Strings vs format() vs % Formatting

Python has three string formatting styles, and all three of them can produce exactly the same output. The difference between them is mostly about readability and about how the values reach the text.

name = 'Ada'
score = 99.456

print(f'{name} scored {score:.2f}')
print('{} scored {:.2f}'.format(name, score))
print('%s scored %.2f' % (name, score))

# An f-string can hold an expression and can pad the text to a width.
width = 8
print('|' + f'{name:>{width}}' + '|')
print(f'{3.14159:.2f}')

All three lines print the same sentence, with the score rounded to two decimal places. The format specifiers work in the same way in each style. The .2f part means two decimal places, and the letter f in front of the string is what marks it as an f-string.

The f-string version is the one to prefer in new code, and the reason is that the expression lives inside the braces right next to the text that uses it. An f-string can hold any expression, including a function call or an arithmetic operation, so you rarely need to prepare a separate variable first. The width example shows a nested replacement field. The outer braces hold a format spec, and the inner expression supplies the width, so you get eight characters of right-aligned text inside the pipes. The last line uses the same idea to ask for two decimal places.

Two details are worth knowing. The percent style is the oldest of the three and it comes from C, so its specifiers look different, such as %.2f instead of .2f, and the values must be given in a tuple unless you use a mapping. And str.format with named placeholders is still the right choice when the format string comes from somewhere else, such as a configuration file or a translation catalogue, because named fields can be reordered and can be filled in by a separate function.

The default answer is to use f-strings, and the reason is that they put the expression next to the text that uses it. In an f-string you can see the value and its position in one place, which makes the code easy to scan and hard to get out of order. The other two styles separate the values from the template, and a mismatch between the two is a common source of bugs.

There are three situations where the other styles are still sensible. The first one is a format string that comes from somewhere else, such as a configuration file, a database row, or a translation catalogue, because you cannot build an f-string around a value that only arrives at runtime. The second one is logging. The logging module supports percent-style arguments natively, and passing them as arguments instead of formatting them in advance lets the logger skip the work when that log level is switched off. The third one is older code, where matching the style of the surrounding code matters more than being modern.

str.format has one advantage over f-strings. Named placeholders can be reordered and they can be reused. If you write {name} and {city} in the template and pass in a dictionary, then you can present the same data in a different order without rewriting the template, and that is exactly what localisation libraries do.

There are two cautions for an interview. Percent-style formatting quietly turns a tuple on the right into several separate values, so a single value that happens to be a tuple gives you a confusing error. That is another good reason to prefer f-strings. And in an f-string a literal brace has to be doubled, so printing a piece of JSON means writing those braces as doubled characters, and that is the one genuinely annoying edge case.