On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip <vinay_sa...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
