New submission from Geoffrey Bache <gjb1...@users.sourceforge.net>: Recently tried to use the logging configuration file format as understood by logging.config.fileConfig() and found it very unwieldy for normal usage. I feel it needs to "scale down" better. Some thoughts:
a) It creates handlers whether they're needed or not. This means you cannot leave the handler sections present in your configuration file and just disable and enable the logger by changing the level, or your application will open the files/sockets etc. anyway, whether the loggers are enabled or not. This is bordering on being a bug rather than just an annoyance... b) There is a lot of unnecessary cruft. For example it should be possible to eliminate the [loggers], [handlers] and [formatters] sections. I gather they're there due to a limitation of ConfigParser but I assume this is historical as I can see no good reason for it now. Also, entries should default sensibly, e.g. "qualname" should not be treated as vital but should default to the name in the section header. c) I'd also suggest providing a newer, non-back-compatible format alongside the existing one that was less wordy for normal use. Get rid of the separate "handlers" and "formatters" and make each logger have a section of its own containing all "handling" and "formatting" information: most users aren't going to want to think about these things as separate entities and in any case there is the hierarchical mechanism to prevent too much copying. In fact, I'd suggest extending the "basicConfig" idea to be able to call it on individual loggers, and build a new format around that, where each section is read and a logger created with the contents passed as keyword arguments to "basicConfig". I might have time to do some of this myself but I want to be sure people think it's a good idea before investing time in it. ---------- components: Extension Modules messages: 88467 nosy: gjb1002 severity: normal status: open title: Make logging configuration files easier to use type: feature request _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6136> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com