Logging ancestors ignored if config changes?
vinay_sajip at yahoo.co.uk
Sat Apr 26 17:05:31 CEST 2008
On 26 Apr, 04:02, andrew cooke <and... at acooke.org> wrote:
> I am seeing some odd behaviour withloggingwhich would be explained
> if loggers that are not defined explicitly (but which are controlled
> via their ancestors) must be created after theloggingsystem is
> configured via fileConfig().
> That's a bit abstract, so here's the problem itself: I define my log
> within a module by doing
> log =logging.getLogger(__name__)
> Now typically __name__ will be something like "acooke.utils.foo".
> That happens before the application configureslogging, which it does
> by callinglogging.config.fileConfig() to load a configuration.
> If I do that, then I don't see anyloggingoutput from
> "acooke.utils.foo" (when using "log" from above after "fileConfig" has
> been called) unless I explicitly define a logger with that name.
> Neither root nor an "acooke" logger, defined in the config file, are
> Is this a bug? Am I doing something stupid? To me the above seems
> like a natural way of using the system...
It's not a bug, it's by design (for better or worse). A call to
fileConfig disables all existing loggers which are not explicitly
named in the new configuration. Configuration is intended for one-off
use rather than in an incremental mode.
Better approaches would be to defer creation of the loggers
programmatically until after the configuration call, or else to name
them explicitly in the configuration.
More information about the Python-list