> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4