Incompatibility between import-time log naming with logging configuration

I am setting up Python logging in main.py by reading in a file and using the fileConfig parameter . I want to be able to switch between test and live logging configurations, so first I want to read in and extract from a separate configuration file the path to the logging configuration file.

The problem is that other files that I import from main.py are grabbing their own log with log = getLogger(__name__)

, and this happens during import. These links then break when a new config is loaded and these modules end up without logging as I expect.

I can't easily delay importing these modules without a lot of refactoring, so is there any other way to keep this method of setting up loggers by module name when loaded in the log configuration later?

+3


source to share


1 answer


I'm not sure about your question how things are, but this is how I see it. The various modules that have log = logging.getLogger(__name__)

will have the correct names for their loggers (log name = package name), unless you have to move the modules to a different package location in some way.

At import time, the logging configuration may or may not be present, and there should be no actual logging calls made as a side effect of the import (if any, the messages have nowhere to go).

Loading a new configuration with fileConfig

usually just sets the handlers, formatting and levels on the registrars.



When you subsequently call the code in the imported modules, they register through their registrars, which have handlers attached by your previous call to config, so they'll output as configured.

You should be aware that in older versions of Python (<= 2.5), calls fileConfig

would inevitably disable existing logs that were not specified in the configuration - in later versions of Python (> = 2.6), this is configured using the keyword argument disable_existing_loggers=False

passed to fileConfig

... You can check this as it sometimes leads to unexpected behavior (default for this setting True

, for compatibility with behavior in older Python versions).

If you post more details on what appears to be broken, I could provide a better diagnosis of what is going on.

+2


source







All Articles