Python F-String Cheat Sheets (2022)
Posted5 months agoActive5 months ago
fstring.helpTechstory
calmmixed
Debate
60/100
PythonString FormattingF-Strings
Key topics
Python
String Formatting
F-Strings
A Python f-string cheat sheet was shared, sparking a discussion on the usefulness and complexity of f-strings, with some users praising their power and others criticizing their readability.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
2h
Peak period
12
6-9h
Avg / period
4.2
Comment distribution38 data points
Loading chart...
Based on 38 loaded comments
Key moments
- 01Story posted
Aug 21, 2025 at 1:08 AM EDT
5 months ago
Step 01 - 02First comment
Aug 21, 2025 at 3:03 AM EDT
2h after posting
Step 02 - 03Peak activity
12 comments in 6-9h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 22, 2025 at 1:16 PM EDT
5 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 44969221Type: storyLast synced: 11/20/2025, 5:45:28 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://peps.python.org/pep-0498/
> This PEP is driven by the desire to have a simpler way to format strings in Python.
I think f-strings have become the thing they were trying to replace and they are now more complicated than the old % interpolation.
I still like f-strings and use them a lot but if you look at the cheat sheet, they are no longer simple.
Most of the formatting options in the cheat sheet have always been available with f-strings. They are part of the Format Specification Mini Language (https://docs.python.org/3/library/string.html#format-specifi...) and both string.format and f-strings use the same spec. f-strings have some additional capabilities like inline expressions and debugging/logging with `=`.
%-style interpolation supports many of these features, they just weren't as well known or discussed back then. The % style is also more complicated because of the weird edge cases (like trying to interpolate a single value which is a tuple).
Once a reader could be reasonably expected to consult reference material while working out what a print() is doing something has gone wrong. This is the programmer equivalent of wearing too much makeup.
When documentation isn't this thorough, people complain about that, too.
On the other hand, you have formatting as an expression that evaluates to a string like f"..." in Python, vs formatting as a set of functions that take the same input format but do various things like printf/snprintf/write!/format!/std::print/std::format... Here it seems Python's approach had too many drawbacks, considering they just added formatted templates t"..." that don't evaluate to a string.
If I were to design a new language, I would use a Python-like "{expr:fmt}" syntax for formatting, but I would make it evaluate to some sort of FormatTemplate object that code can inspect.
That's not a fair characterization at all, since the plan was always to add something like the t"" strings. Having a version that immediately evaluates to a string is convenient, and adds very little complexity either at the implementation level or conceptually.
Are there languages which only have an f-string-like feature without a `string.format` equivalent?
(I've been thinking about this for a while, actually. Since PEP 751 was still in discussion.)
f-strings put the value in the output string exactly where the value should be. Massive win for contextual awareness, no need to count ...3, 4, okay what's the position 4 value over on the right, does it match up?? And they use classic Python string formatting commands, except the = operator which makes them even better with a "name the variable, show its value in a concise way" option. What's not to like?
(And if you don't like them, uh...they're not mandatory. Just don't use them.)
It is probably some sort of deep seated printf() based trauma.
I even get to keep the idea of being able to read the vars in-place in the string which is certainly the last thing that I needed to be happy to use them! Full convert now!
I'm also the author of https://fstring.help/cheat/ (though not of the homepage) and I haven't yet linked back to that new tool. I was surprised to the cheat sheet here today but not the format guesser.
At the very least, your tool wasn't able to figure it out and hardcoded most of the number I wrote in.
"STRING" + str(var) + "STRING"
keep in mind that for long strings, each `+` creates a new string object (at least, it did in the 2.x days and I assume it hasn't changed)
#instant, does not consume twice as much memory. s+="a"
I don't know the internals, but certainly there's not a new string being created. Maybe if it exceeds capacity? Who cares at that point, it's python strings, not Matmuls in C.
But this page isn't about merely inserting a number/string into a string, it's about expressing how you want that number/string formatted. Maybe you only want the first two digits after a decimal. Maybe you want it to always be the same width and to pad with spaces or zeroes. Or any other ways of formatting.
Also, even though use in log messages is discouraged, I go ahead and use them. It will let me know if there is some code path where the proper variable is never set. This usually comes out through testing, especially during fuzzing so I guess it really only works because of my testing, otherwise it would come up during runtime...