On Wed, 04 Dec 2013 09:34:13 +0800, Zhang Weiwu wrote: > Why would anyone use [logging.config.listen()]? I can't think of use > cases when one need to change logging configuration dynamically > through socket, but not needing the same flexibility on overall > configuration for his application (configparser). It feels strange to > design a socket interface only to expose logging configuration. If you > use logging.config.listen, I very much wish to know what problem are > you attacking.
Consider a long-running process that listens for input (HTTP, CLI, GUI, or something else; it doesn't matter), does some processing, and produces output. A web server is an example of such a process. Now consider the case that something is wrong with the process, but you're not sure what. So you use logging.config.listen to raise the logging level so that you can see more logging from your process without disturbing it in any way. Or suppose you want to deploy a new plug-in to the process, and temporarily turn "up" the logging to watch the new plug-in emit some debugging-level messages as it starts up. When the new plug-in is finished, you can turn "down" the logging level. With logging.config.listen(), you can do all of this without stopping and restarting the process. > I imagined this use case, and invite you to debate if it be > valid. Thanks. I think your use case is equivalent to the ones I described. Therefore, it is valid. ;-) > It begets the question, that if it is easier to write a > socket-listening loging handler and forget all about > logging.config.listen() stuff. I never did it before, hence the > question. But why develop all of that code when logging.config.listen() already exists? Adding a new SocketHandler seems more heavyweight (and more risky) than adjusting the logging level on an existing SocketHandler. HTH, Dan -- https://mail.python.org/mailman/listinfo/python-list
