[Python-Dev] A proposal: configuring logging using dictionaries
vinay_sajip at yahoo.co.uk
Sat Oct 17 10:53:59 CEST 2009
Nick Coghlan <ncoghlan <at> gmail.com> writes:
> 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'm happy with this. I've subscribed to the PEPs list and once the subscription
comes through, will post there linking to the PEP draft.
> 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?
I was thinking that in some environments, configuration changes might be sent as
pickled dicts over the wire. In such cases it might be useful to have the
"incremental" flag in the payload. But I haven't thought that through in detail,
as it's somewhat peripheral to this feature.
> 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.
Another fair point - perhaps a getConfig() which returns a dict can be added.
> 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.
Perhaps TypeError, too. The idea is to definitely pinpoint where in the
configuration the error occurred. I'll think about the detail of this a bit
further down the line, but I just wanted to establish that I wasn't planning on
introducing any logging-related exception classes.
Thanks for the quick response and detailed feedback.
More information about the Python-Dev