[Python-Dev] A new way to configure logging (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Wed Oct 7 18:55:48 CEST 2009

Paul Rudin <paul at ...> writes:

How about the global logging configuration being available as an object supporting the usual dictionary interface? So you could, for example, do something like: "logging.dictconfig.update(partialconfig)"

A "partial configuration" only makes sense under certain limited conditions. For example, a dict used for configuration will map to a graph of objects - filters, formatters, handlers and loggers - which by necessity need to be referred to via a string key in the dict - because you can't easily encode a graph in a dict which comes from, say, a YAML or JSON file. These keys are temporary and just used to indicate e.g. which handlers to attach to which loggers for that particular configuration call:

{ "handlers": { "h1": { configuration for a handler }, "h2": { configuration for another handler }, "h3": { configuration for yet another handler }, }, "loggers": { "foo": { "level": "DEBUG", "handlers": ["h1", "h3"], }, "bar.baz": { "level": "INFO", "handlers": ["h2", "h3"], }, "spam.eggs": { "level": "ERROR", "handlers": ["h1", "h3"], }, } }

Here, the keys "h1", "h2" etc. are just used to encode connections in the graph, and are useless outside the context of the specific configuration call. If you pass a partial configuration, to be implemented incrementally, there's no way of knowing if (in general) it's going to be consistent with the existing configuration. Nor can you refer to e.g. handlers, formatters or filters you passed in earlier configuration calls.

Since logger names such as "foo", "bar.baz" in the above example are meaningful across multiple configuration calls, it would be possible to make certain changes in the configuration - such as changing levels of loggers - by passing in a partial configuration. However, if this "partial" functionality is provided without restriction, it's hard to ensure that a user doesn't inadvertently misconfigure logging. And while that is equally true with a one-shot configuration, it's at least easier to debug. Things can get pretty murky from a diagnostic point of view if code can make arbitrary changes to the logging configuration during application execution, so that's not a good practice to encourage :-)

Also, providing a readable dict-like interface to the internal configuration will almost certainly lead to backward-compatibility headaches in the future.

Regards,

Vinay Sajip

More information about the Python-Dev mailing list