Python 3.7日志记录:f字符串与%

the*_*heG 12 python python-3.x

我在一个项目中遇到性能问题,并将其缩小到某些日志行。似乎即使我的日志记录工具高于正在记录的行的级别,也可以计算f字符串。

考虑以下示例以演示该问题:

import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger('MyLogger')

class MyClass:
    def __init__(self, name: str) -> None:
        self._name = name
    def __str__(self) -> str:
        print('GENERATING STRING')
        return self._name

c = MyClass('foo')
logger.debug(f'Created: {c}')
Run Code Online (Sandbox Code Playgroud)

运行此示例时,我将在屏幕上打印“ GENERATING STRING”,表示__str__即使将我的日志记录级别设置为INFO,并且日志行为,该方法也正在运行DEBUG

据我今天所知,解决方案是使用以下vs f字符串。

logger.debug('Created: %s', c)
Run Code Online (Sandbox Code Playgroud)

我现在脑子里发生了三件事。

  • 我阅读的大多数示例和文档似乎都很老。
  • 该项目仅适用于Python 3.7+(不担心向后兼容)。
  • 我有很多代码行需要更新。

我很想知道其他人在这种情况下会做什么。是%s最好的(最现代的)办法?如上所述,有没有更现代的方式记录我的日志?

我有很多代码需要更新(修复),我希望与现代最佳实践保持一致。

Ant*_*ane 10

IMO,%s在您的字符串中使用不是最现代的方法。毫无疑问,大多数开发人员将更喜欢使用f字符串,因为它更加方便且易于读取(和写入)。

但是,有趣的是,您发现了一个特定的情况,您可能不想使用f字符串。如果__str__()由于优化问题而需要避免自动调用方法,那么使用%sf字符串可能是一个足够好的理由。但是,这也可能表示您可以在程序中进行某些操作以降低的复杂度__str__()。在大多数情况下,为对象计算字符串表示形式不需要花费太多时间或资源...

  • 查看http://docs.python.org/3/howto/logging.html#optimization:“消息参数的格式被推迟,直到无法避免为止。”。使用 f 字符串语法可能会产生提取成本,因为即使未记录消息,它也会格式化消息。有关其他信息,请参阅 http://docs.python.org/3/howto/logging.html#optimization。 (14认同)
  • 同意,我绝对更喜欢 f 字符串语法。在本例中,“__str__”方法将纪元时间戳转换为人类可读的日期。这是一个性能问题,因为它在调试日志记录中被调用了数百万次。 (5认同)

oli*_*x14 7

文档说,日志记录库已优化为使用%s格式化样式。我不记得确切提到了什么地方,但是几个月前我读了它。

编辑 -找到!https://docs.python.org/3/howto/logging-cookbook.html#formatting-styles
EDIT2 - (感谢罗宾内梅特)https://docs.python.org/3/howto/logging.html#优化

  • 这是链接https://docs.python.org/3/howto/logging.html#optimization (2认同)
  • 太糟糕了,我认为 f 字符串更具可读性。 (2认同)