As pointed out by @shmee in this answer, the logger hierarchy must be defined explicitly in the logger name, using dot-notation. That is, if the logger name in main_module.py
is e.g. 'a'
, then the logger name in auxiliary_module.py
must be 'a.b'
(not just 'b'
), in order for it to inherit the configuration of logger 'a'
. This is also mentioned in the getLogger()
documentation.
However, this should be taken care of automatically when using __name__
, as noted in the logging
how-to:
This means that logger names track the package/module hierarchy, and it’s intuitively obvious where events are logged just from the logger name.
The thing is, for this to work, you need to use __name__
in the correct way, and I did not do that.
The problem in my example is in the organization of the files in the cookbook-example
package folder:
Both the main module and the auxiliary module are at the same level (i.e. in the same folder). So, as explained here, the __name__
for the main module will then be '__main__'
(as it is the top-level script), and the __name__
for the auxiliary module will be 'auxiliary_module'
(i.e. the filename), NOT '__main__.auxiliary_module'
.
As a result, the logger in the auxiliary module will be a child of the root logger, not a child of the '__main__'
logger, and it will thus inherit the root logger configuration (which still has the default logging level WARNING
) instead of the configuration specified in the main module.
So, to make the example work, we have several options:
-
Replace
getLogger(__name__)
in the main module bygetLogger()
.
This will apply the config to the root logger and therefore also to
the auxiliary module logger, as suggested by @shmee. -
Replace
getLogger(__name__)
in the auxiliary module by
getLogger('__main__.' + __name__)
. The result will be equivalent
to the original cookbook-example (except that the main logger is now called
'__main__'
instead of'spam_application'
).