[Python-Dev] A new way to configure logging

[Olemis Lang]

On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> At present, configuration of Python's logging package can be done in one of two
> ways:
>
> 1. Create a ConfigParser-readable configuration file and use
> logging.config.fileConfig() to read and implement the configuration therein.
> 2. Use the logging API to programmatically configure logging using getLogger(),
> addHandler() etc.
>
[...]

Wow ! Great explanation !
;o)

>
> All three of the contenders for the title of "commonly found configuration
> mechanism" - JSON, YAML and Python code - will be expressible, in Python, as
> Python dicts.

.INI files too

{
  'section1' :
    {'opt11' : 'val1', 'opt12' : 32323},
  'section1' :
    {'opt21' : 'val2', 'opt22' : 32323},
  'section1' :
    {'opt31' : 'val3', 'opt32' : 32323},
...
}

In fact it seems that this is a typical characteristic of config formats (CMIIW)

> So it seems to make sense to add, to logging.config, a new
> callable bound to "dictConfig" which will take a single dictionary argument and
> configure logging from that dictionary.
>

This kind of problems is similar to the one mentioned in another
thread about modifying config options after executing commands. In
that case I mentioned that the same dict-like interface also holds for
WinReg and so on ...

So thinking big (yes ! I have a big head ! ) I think that the best
approach in this case is to build an adaptation (simple) layer on top
of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific
extensions for these formats . Perhaps the proper interfaces are
already there (e.g. `dict`, `shelve` ) and I'm just blind and looking
somewhere else ;o)

If `dict` (possibly nested ;o) is enough to represent config files
then the new method should be ok ... IMHO

[...]
>
> In outline, the scheme I have in mind will look like this, in terms of the new
> public API:
>
> class DictConfigurator:
>    def __init__(self, config): #config is a dict-like object (duck-typed)

========

>        import copy
>        self.config = copy.deepcopy(config)

Why ?

>
>    def configure(self):
>        #  actually do the configuration here using self.config
>
> dictConfigClass = DictConfigurator
>
> def dictConfig(config):
>    dictConfigClass(config).configure()
>
> This allows easy replacement of DictConfigurator with a suitable subclass where
> needed.
>

extension is cool ... what's the point about adding the new method
instead of using `DictConfigurator` directly ?

> What's the general feeling here about this proposal?
>

I'm feeling things ... :)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html