
One is a usability bug: calling fileConfig() disables any logger objects already created that are not explicitly specified in the log config file. Since loggers are often created when a module is
It's not a bug, it's by design. The semantics of fileConfig() is that it completely replaces the existing configuration (in some scenarios, that's what you want). I'm thinking about a better way to configure the system - incremental rather than all-or-nothing. I will update the docstring to indicate this, as it's perhaps not clear enough.
imported, it's hard to keep track of the order in which loggers are created, leading to unexpected behavior because an unspecifed logger created after the call to fileConfig behave differently -- it will inherit its settings from its parent logger. Here's an example illustrating the problem:
import logging, logging.config import mymodule #this module contains a line like log = logging.getLogger("mymodule")
if __name__ == '__main__': loggging.config.fileConfig("log.config") #mymodule.log is now disabled! #this seems like a bad design -- difficult to figure out what's going on #work-around: re-enable the loggers for logger in logging.Logger.manager.loggerDict.itervalues(): logger.disabled = 0
It'd be easier to comment out the line in config.py which sets disabled to 1, if this is behaviour you want in all your applications.
Second, i'd recommend a minor change that would greatly increase the flexibility of the architecture: store the entire keyword dictionary in the LogRecord, not just exc_info -- that way arbitrary objects could be passed to particular handlers or formatters that know how to use them. Some use cases for this:
- pass a unique error number.
- pass structured information about the message, e.g. for writing to a
database table
- for a localized message formatter (LogRecord already stores the
argument list for string interpolation but this is cumbersome for localization since they depends on the order they appear in the message).
The whole area of LogRecord construction needs to be made more extensible. I'm in discussions with Fred Drake about this, and hopefully soon will be able to implement a better mechanism.
Fred - if you're listening - :-)
Thanks for the feedback.
Regards,
Vinay