[Python-Dev] A proposal: configuring logging using dictionaries

[Nick Coghlan]

Vinay Sajip wrote:
> A little while ago, I posted here a suggestion about a new way to configure
> logging, using dictionaries. This received some positive and no negative
> feedback, so I have thought some more about the details of how it might work. I
> present below the results of that thinking, in a PEP-style format. I don't know
> if an actual PEP is required for a change of this type, but I felt that it's
> still worth going through the exercise to try and achieve a reasonable level of
> rigour. (I hope I've succeeded.)

Since part of the purpose of this new configuration option is to allow
other projects to use it as a target for specifying a logging
configuration, maintaining it as a formal PEP seems like a good idea to
me. This is already done for a few other standard-ish interfaces
(distutils metadata, DB-API, WSGI).


> I would welcome all your feedback on this proposal. If I hear no negative
> feedback, I propose to implement this feature as suggested.

My only real objection is to the "incremental" flag in the dictionary. I
would suggest having two different API methods instead - initDictConfig
and updateDictConfig. Or is there some specific reason for having the
choice of incremental update vs replacement configuration in the hands
of the config author rather than the application developer?

My other question is whether or not it would be worth having the logging
module able to export it's *current* configuration in dictionary form. I
don't have a use case other than that it might be useful for debugging
logging configuration errors when attempting to combine multiple sources
of logging data, but it's worth considering.

> So, for example, consider the following YAML snippet::
>   
>   handers:
>     h1: #This is an id
>      # configuration of handler with id h1 goes here
>     h2: #This is another id
>      # configuration of handler with id h2 goes here

Typo in the header here: s/handers/handlers/


> Configuration Errors
> ====================
> 
> If an error is encountered during configuration, the system will raise a
> ``ValueError`` or a ``TypeError`` with a suitably descriptive message. The
> following is a (possibly incomplete) list of conditions which will raise an
> error:
> 
> * A ``level`` which is not a string or which is a string not corresponding to
>   an actual logging level
> 
> * A ``propagate`` value which is not a Boolean
> 
> * An id which does not have a corresponding destination
> 
> * An invalid logger name

You may want to allow yourself AttributeError and ImportError here.
Alternatively, you could commit to converting those to an appropriate
ValueError that provides more detail on the config setting that
contained the problematic reference.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------