False positive logging-format-truncated using percentage in the message without args

[moylop260]

Bug description

import logging

logging.info('Good percent %')

Configuration

Command used

pylint --logging-format-style=old -d all -e logging-format-truncated --rcfile=/dev/null my_file.py

NOTE: Using --logging-format-style=new format is not reproduced

Pylint output

E1201: Logging format string ends in middle of conversion specifier (logging-format-truncated)

Expected behavior

The percentage value is valid and it doesn't need to be scaped if there are not args to parse in the string

Notice the following example where the value is showed correctly without scaping vs scaping the value:

• 

Pylint version

pylint 4.0.0-dev0
astroid 4.0.0a0
Python 3.12.11 (main, Jun  3 2025, 15:41:47) [Clang 17.0.0 (clang-1700.0.13.3)]

OS / Environment

MacOSX

Additional dependencies

[daltonbohning]

It seems v4.0.0 was released with this issue still present. As far as I can tell, the only workaround is to disable this check?

[Pierre-Sassoulas]

You can disable it locally when the % is legit with # pylint: disable-next=logging-format-truncated. If you want to "fix" this I guess it shouldn't raise when there's no argument to be processed ? i.e. logging.info('Bad percent %', arg) raise but not logging.info('Good percent %'). But then it wouldn't catch double errors, so I don't know, maybe the false positive is acceptable, what do you think ? Personally I use the new logging format.

[daltonbohning]

I would hope we don't have to disable it, since the % is valid when there are no arguments. When there are no arguments, all % are treated literally, but if there is at least one argument then all % must be valid format specifiers or must be escaped like %%.

What new logging format are you referring to?

[Pierre-Sassoulas]

The decision was taken in #9999 (comment), and implemented in #10321, we caught 4 false negatives and no false positives in the primer at the time #10321 (comment).

I meant --logging-format-style=new (using f-strings in logging, the perf impact of doing this is negligible)

[daltonbohning]

Okay, I see. It seems the real problem lies with how python handles this, so the linter can never be perfect. I can live with this - thanks!