> The submodule logging/config.py contains code that I feel should not > be there. I experimented with the config file format it implements, > and it appears very painful. It's not ideal, but a ConfigParser-based format seemed the thing to use since it's already part of Python. You don't need to specify things twice - that's a side effect of using the GUI configurator to create a config file. (N.B. The GUI configurator is not part of the package proper.) For a handler, you need only specify the class, the level, the formatter, and the args for the constructor. I agree that the config file format documentation leaves a lot of room for improvement. But it's not as bad as all that, once you get past the original irritation. > Since configuring the logging package with a few programmatic calls is > so easy, and applications that need serious logging configurability > typically already have some configuration mechanism, I propose to drop > this from the Python distribution. -0. > I'm similarly not convinced of the utility of the logging/handlers.py > submodule, but I've never tried to use it, so lacking any particular > negative experience all I can say against it is YAGNI. -1. That may be because you've never yet wanted to do anything other than log to console or file. I think it should be left in as without it, logging is most definitely not "batteries included". For example, it provides syslog, socket, datagram, email, HTTP and memory-buffering handlers. Perhaps these questions could be asked on python-list? I am aware of many users who use the handlers in the logging.handlers module (though there are fewer who have given feedback about the config capability). 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