Except that f-strings are not lazy evaluated so you cannot replace something like:
log.debug("foo bar %s", foobar)
with fstrings. And you end up with part of your team enforcing f-strings because of cleaner look, the other half .format or '%' strings and the rest annoyed when their code is constantly rejected in reviews because they don't know/care which standard to use where.
My understanding was that you can use f-strings for the thing you outlined above, the f-string composition will just be evaluated as an expression whether or not log.debug is enabled. Personally I'd trade that for the %-string drawbacks.
I was reading a recent bug report where they were going back and forth on this. f-strings were so performant there wasn't much difference between lazy evaluation (not evaluating them) and f-strings. The sticking points seemed to be a) if your f-string variable took unreasonably long to compute or b) if evaluating your variable caused an error.
I get all of these arguments. I see formatting errors so often in error handling code I would much prefer they'd get caught during normal execution. I can't see trusting a heavy query to lazy evaluation...or see it coming up all that often.
I see both sides, but really think using f-strings in logging is the right compromise for Python...but I just don't see them dropping c-style formatting.
Languages don't solve organizational issues. If you have a dysfunctional team without leadership then that will always show somewhere. A good team would establish some set of coding standards and then enforce those. Rejecting PRs for personal preference coding standards would result in a talk from the manager.
I don't think something like "foo bar %s".format(foobar) would work either in this situation. I think you're conflating format strings with the lazy evaluation associated with logging.
I am, however, in complete agreement that logging should adopt at least the same formatting used by .format
