Why get a new logger object in each new module?
<p>The python logging module has a common pattern (<a href="http://stackoverflow.com/a/15735146/52074">ex1</a>, <a href="https://docs.python.org/2/howto/logging.html#advanced-logging-tutorial" rel="nofollow">ex2</a>) where in each module you get a new logger object for each python module.</p>

<p>I'm not a fan of blindly following patterns and so I would like to understand a little bit more.</p>

<p><strong>Why get a new logger object in each new module?</strong></p>

<p>Why not have everyone just use the same root logger and configure the formatter with <code>%(module)s</code>?</p>

<p>Is there examples where this pattern is NECESSARY/NEEDED (i.e. because of some sort of performance reason[1])?</p>

<p>[1]
In a multi-threaded python program, is there some sort of hidden synchronization issues that is fixed by using multiple logging objects?</p>

<p>The logger name defines <em>where</em> (logically) in your application events occur. Hence, the recommended pattern</p>

<pre><code>logger = logging.getLogger(__name__)
</code></pre>

<p>uses logger names which track the Python package hierarchy. This in turn allows whoever is configuring logging to turn verbosity up or down for specific loggers. If everything just used the root logger, one couldn't get fine grained control of verbosity, which is important when systems reach a certain size / complexity.</p>

<p>The logger names don't need to exactly track the package names - you could have multiple loggers in certain packages, for example. The main deciding factor is how much flexibility is needed (if you're writing an application) and perhaps also how much flexibility your users need (if you're writing a library). </p>

python multithreading performance logging instrumentation