any use case of logging.config.listen()?
dan at tombstonezero.net
Wed Dec 4 04:05:38 CET 2013
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
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.
More information about the Python-list