次のコードの場合：
logger.debug('message: {}'.format('test'))pylint 次の警告が生成されます。
ロギングフォーマット補間（W1202）：
ロギング関数で％フォーマットを使用して、引数として％パラメーターを渡します。ロギングステートメントに「logging。（format_string.format（format_args ...））」の呼び出し形式がある場合に使用されます。そのような呼び出しでは、代わりに％形式を使用する必要がありますが、引数としてパラメーターを渡すことにより、ログ関数に補間を残します。
この警告をオフにできることはわかっていますが、理解したいと思います。format()Python 3でステートメントを出力する方法として、を使用するのが望ましいと思いました。ロガーステートメントにこれが当てはまらないのはなぜですか？
回答:
これは、ロガー呼び出しに渡される追加の引数を使用してこの文字列の遅延補間を提供するために、文字列のような以前の「％」形式に依存しているため、ロガーステートメントには当てはまりません。たとえば、代わりに：
logger.error('oops caused by %s' % exc)やったほうがいい
logger.error('oops caused by %s', exc)そのため、メッセージが実際に発行された場合にのみ文字列が補間されます。
を使用して.format()いる場合は、この機能を利用できません。
あたりの最適化のセクションloggingドキュメント：
メッセージ引数のフォーマットは、回避できなくなるまで延期されます。ただし、loggingメソッドに渡された引数を計算することも負荷が高くなる可能性があり、ロガーがイベントを破棄するだけの場合は、それを避けたい場合があります。
.format()ので、ある時点でスタイルに移行するために、pylintによって後で「推奨」さloggingれますか？少なくともほとんどのタスクで、最先端の速度パフォーマンスよりも保守性に関心があるので、質問します。
たぶん、この時間差が役立つかもしれません。
次の説明はあなたの質問に対する答えではありませんが、人々を助けることができます。
pylint 2.4の場合：でスタイルを記録するための3つのオプションがあり.pylintrcます。ファイルはold、new、fstr
.pylintrcファイルからの説明（v2.4）：
[LOGGING]
# Format style used to check logging format string. `old` means using %
# formatting, `new` is for `{}` formatting,and `fstr` is for f-strings.
logging-format-style=old以下のための古いです（logging-format-style=old）：
foo = "bar"
self.logger.info("foo: %s", foo)以下のための新しいです（logging-format-style=new）：
foo = "bar"
self.logger.info("foo: {}", foo)
# OR
self.logger.info("foo: {foo}", foo=foo)注：オプションを選択しても使用できません。.format()new
pylint はこのコードに対しても同じ警告を出します：
self.logger.info("foo: {}".format(foo)) # W1202
# OR
self.logger.info("foo: {foo}".format(foo=foo)) # W1202用FSTR（logging-format-style=fstr）：
foo = "bar"
self.logger.info(f"foo: {foo}")個人的に、私はPEP-0498のためにfstrオプションを好みます。
"python.linting.pylintArgs": ["--logging-format-style=old"]vscode / settings.jsonファイルに追加できます。docs
optparse.OptionValueError: option logging-format-style: invalid value: 'fstr', should be in ['old', 'new']最新のpylint（2.4.4）にアップグレードすると、これが修正されました。
Try installing a more recent version of python-pylint, and please open a bug report if the issue persists in t\ he latest release. Thanks!
私の経験では、遅延補間の最適化（ほとんどのユースケースの場合）よりも説得力のある理由は、Sentryのようなログアグリゲーターでうまく機能するためです。
「ユーザーがログインしました」というログメッセージについて考えてみます。ユーザーをフォーマット文字列に挿入すると、ユーザーの数と同じ数の個別のログメッセージが表示されます。このような遅延補間を使用する場合、ログアグリゲーターは、これをより多くの異なるインスタンスを持つ同じログメッセージとしてより合理的に解釈できます。