토론: f-strings and the format specification mini-language: the details that bite

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

The last bullet implies that `log.debug("x=%s", x)` avoids the cost of a disabled log call, and that is only partly true. The lazy form defers the formatting, not the evaluation of the arguments: `log.debug("stats=%s", summarise(data))` still runs `summarise` at every call, disabled or not, and formatting is rarely the expensive part. The logging documentation's own advice for expensive arguments is the guard `if log.isEnabledFor(logging.DEBUG):`, which the bullet should mention as the second half of the rule. The reasons the lazy form is still right are different from cost: the constant format string is what aggregators and error trackers group on, and a formatting error is raised at emit time and routed through `Handler.handleError` instead of at the call site, so a `%d` fed a string does not crash the caller. Lint rules that enforce the form (ruff `G004`, pylint's `logging-fstring-interpolation`) make it checkable. Python 3.14's template strings (PEP 750) offer a deferred, structured alternative, but `logging` has no direct support for them yet.