Yeah, it’s also surprising because the user really shouldn’t be using f-strings for logging since they get interpolated whether or not the log level is set to INFO. This is more important when the user is writing say, debug logs that run inside hot loops, which will incur a significant performance penalty by converting lots of data to its string representation.
f""-strings for logging is an example of "practicality beats purity"
Yes, f""-strings may be evaluated unnecessarily (perhaps, t-strings could solve it). But in practice they are too convenient. Unless profiler says otherwise, it may be ok to use them in many circumstances.
Heh, I get to totally dunk on this guy by calling him a vibe coder for not using lazy evaled string interpolation.
Wait a second.. If I do ANY ACTUAL engineering and log out the time savings, it's completely negligible and just makes the code harder to read?
It is complete insanity to me that literally every piece of programming literature over the past sixty years has been drilling the concept about code readability over unncessary optimizations and yet still I constantly read completely backwards takes like this.
Having strong opinions on technical errata makes you sound smart and like you know what you're doing to the people who might want to hire you. Saying "I didn't bother to optimize this because it doesn't affect our bottom line" can be so easily reinterpreted as "I'm incompetent and never even thought about this angle in the first place". The OP has chosen an effective middle ground to communicate that they're serious about their work.
Yeah, so like I said, it’s not a problem, until it is. The gist of the article is that “LLMs let me add a lot of useful debugging messages to my logs”, that’s great, I use them for log messages too, but not with f-strings.
The footgun is there. Hot-loop debug logging can cost a ton with f-strings, and an LLM can just as easily use the standard log formatting without this problem. Few people use a profiler prior to a production bug (or just end up with eye popping autoscaling bills).
Shrug. I guess everyone can learn for themselves if it’s a problem for them. But I’ve been there; it would be nice if the tools did better with best practices.
> you should be interpreting them at time of reading the log
This reminds me of a fun interaction in browser devtools: you can log a complex struct to the console. The browser does not copy the entire nested structure when you do so immediately, meaning that if someone mutates that struct after it was logged, the value you see depends on when you expanded the nested struct.
The thing is, the logging calls already accept variable arguments that do pretty much what people use f-string in logging calls for already, except better. People see f-string, they like f-string, and they end up in logs, that's really all there is to it.
But sure, vibe away.