为什么要在每个新模块中获取新的记录器对象？

python日志记录模块有一个通用模式（ex1,ex2），其中每个模块中为每个python模块获取一个新的日志记录器对象。为什么要在每个新模块中获取新的记录器对象？

我不是盲目追随模式的粉丝，所以我想多了解一点。

为什么要每一个新的模块中的一个新的记录器对象？

为什么不让每个人都使用相同的根记录器并将格式器配置为%(module)s？

是否有示例，其中该模式是必要的/需要（即某种性能原因[1]，因为）？

[1] 在一个多线程的python程序中，是否存在某种通过使用多个日志记录对象修复的隐藏同步问题？

来源

2016-09-22 Trevor Boyd Smith

相关的问题，但可能需要一个新的计算器问题本身：如果您有多个日志记录都使用相同的控制台，流对象，和/或文件处理程序是有一个隐藏的同步问题（只有一个线程可以读/写的文件一次）？ –

'logging'被定义为线程安全的，因此记录器*可以使用锁写入其日志。这意味着在多线程环境中使用是安全的。但是请注意，在unix系统上使用多处理时，这是一个众所周知的问题：默认情况下'fork'不会复制锁并在罕见情况下导致死锁。看[这里]（http://stackoverflow.com/questions/24509650/deadlock-with-logging-multiprocess-multithread-python-script）。 – Bakuriu

每个记录器可以单独配置。一般来说，模块本身并没有配置模块记录器，所有。您可以创建一个独特的记录器并使用它来记录不同级别的详细信息。无论谁使用使用记录器都会决定要查看的消息级别，发送消息的位置以及如何显示它们。他们可能希望将一个模块的所有内容（DEBUG及以上）记录到一个文件中，而另一个模块则可能只关心是否发生严重错误（在这种情况下，他们希望通过电子邮件直接发送给他们）。如果每个模块使用相同的（根）记录器，则不会有这种灵活性。

来源

2016-09-22 15:46:02 chepner

记录器名称定义凡在你的应用程序事件（逻辑）发生。因此，推荐模式

logger = logging.getLogger(__name__)

使用跟踪Python包层次结构的记录器名称。这反过来又允许任何正在配置日志记录的人为特定记录器打开或关闭详细信息。如果一切都只使用根记录器，则无法获得细节的细节控制，当系统达到一定的大小/复杂度时这一点很重要。

记录器名称不需要精确地跟踪包的名字 - 你可以在一定的封装中的多个记录器，例如。主要的决定因素是需要多大的灵活性（如果你正在编写一个应用程序），也许还需要你的用户需要多大的灵活性（如果你正在编写一个库）。

来源

2016-09-22 15:47:19

“当系统达到一定的大小/复杂度时”：我认为在中小程序中，模式并不那么重要。但随着你的复杂性/规模的增长...这种模式变得更加重要/必要。 –

@TrevorBoydSmith没错。 –

为什么要在每个新模块中获取新的记录器对象？

回答

相关问题