Introduction

PyLint's logging-format-interpolation warning appears when a logging call builds the final message string too early, usually with an f-string or another interpolation technique. The warning exists because Python's logging module is designed to do lazy formatting: the logger should receive the format template and the arguments separately.

That lazy pattern matters because the message only needs to be formatted if the log level is actually enabled. If a debug message is skipped, expensive interpolation work can be skipped too.

What Triggers The Warning

These patterns commonly trigger the warning:

1import logging
2
3user_id = 42
4duration = 1.83
5
6logging.info(f"User {user_id} finished in {duration} seconds")
7logging.info("User %s finished in %s seconds" % (user_id, duration))
8logging.info("User {} finished in {} seconds".format(user_id, duration))

All three calls build the final string before passing it to the logger. That works functionally, but it defeats the logger's built-in lazy formatting behavior.

The Preferred Logging Style

Pass the format string and the arguments separately:

1import logging
2
3user_id = 42
4duration = 1.83
5
6logging.info("User %s finished in %s seconds", user_id, duration)

The logging module stores the template and arguments, then formats the message only if the record is emitted. This is the style PyLint expects because it is efficient and consistent with the logging API.

This style also keeps structured data separate from the message text for longer, which can help custom formatters and logging adapters.

Why F-Strings Are Different Here

F-strings are great in normal Python string-building code, but logging is a special case. With an f-string, Python must evaluate the expression immediately:

expensive_value = compute_something()
logging.debug(f"Result: {expensive_value}")

Even if debug logging is disabled, compute_something() already ran and the string already exists. With lazy logging, you can delay the formatting cost, though note that the arguments themselves are still evaluated before the call. The main saving is the construction of the final message string and the consistency of the logging pattern.

Exceptions And Practical Tradeoffs

There are cases where preformatted logging is acceptable, such as one-off scripts or code paths where the string is already computed for another reason. But in application code, team conventions and lint rules usually prefer the lazy form because it scales better and keeps log statements uniform.

For exception logging, the same idea applies:

1try:
2    1 / 0
3except ZeroDivisionError:
4    logging.exception("Failed to process user %s", user_id)

That produces the stack trace while still following the logging API correctly.

Common Pitfalls

The most common mistake is assuming the warning means % formatting is forbidden everywhere. It is not. PyLint is specifically telling you to use logging's argument-based %s placeholder style inside logging calls. Another mistake is switching to .format() or f-strings, which often looks cleaner but still triggers the same underlying issue. Developers also sometimes misunderstand the performance benefit and think argument evaluation is fully avoided. It is not. The gain is that the final message formatting is deferred until the logger decides to emit the record. Finally, keep placeholder counts aligned with the arguments. A mismatch may only show up when the log line is emitted, which makes it easy to miss in lightly tested paths.

Summary

• 'logging-format-interpolation warns when a log message is interpolated before it reaches the logger.'
• Prefer logging.info("User %s", user_id) over f-strings or .format() inside logging calls.
• The logging API formats the message lazily when the record is emitted.
• Use the same argument-based pattern for exception logging.
• Keep placeholder counts and argument lists aligned so emitted log lines do not fail at runtime.