[Python-Dev] A new way to configure logging

[Vinay Sajip]

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