[Python-Dev] A new way to configure logging

[Doug Hellmann]

On Oct 8, 2009, at 10:47 AM, Vinay Sajip wrote:

>> I've had bad experiences in the past with dictionary-based APIs.   
>> They seem
>
>> "simpler" in the short run, because the user "only needs to create  
>> some
>> dictionaries".  Once the complexity of that nested dictionary grows  
>> to a certain
>> point, though, one has to refer back to documentation constantly to  
>> make sure
>
> Fair point, and agreed that the schema needs some care, here's  
> roughly what I'm thinking of as an example configuration (YAML):
>
> formatters:
>  brief:
>    format: '%(levelname)-8s: %(name)-15s: %(message)s'
>  precise:
>    format: '%(asctime)s %(name)-15s %(levelname)-8s %(message)s'
> filters:
>  allow_foo:
>    name: foo
> handlers:
>  console:
>    class : logging.StreamHandler
>    formatter: brief
>    level   : INFO
>    stream  : sys.stdout
>    filters: [allow_foo]
>  file:
>    class : logging.handlers.RotatingFileHandler
>    formatter: precise
>    filename: logconfig.log
>    maxBytes: 1024
>    backupCount: 3
>  debugfile:
>    class : logging.FileHandler
>    formatter: precise
>    filename: logconfig-detail.log
>    mode: a
> loggers:
>  foo:
>    level : ERROR
>    handlers: [debugfile]
>  spam:
>    level : CRITICAL
>    handlers: [debugfile]
>    propagate: no
>  bar.baz:
>    level: WARNING
>
> root:
>  level     : DEBUG
>  handlers  : [console, file]
>
> It's not too deeply nested, and I can't see any need for it being  
> more deeply nested. It more or less mirrors the way you'd have to  
> write the corresponding ConfigParser-compatible configuration, but  
> if you use a dict as a common format, you have the benefits which I  
> mentioned of supporting JSON, YAML or Python code in a Django  
> settings.py.

Yes, that makes sense.

>> the structure conforms to the "schema".  Building a simple config  
>> tree using
>> light-weight classes with documented APIs tends to be more  
>> sustainable in the
>> long run.
>
> When you say 'config tree using light-weight classes', I presume you  
> mean a parallel set of classes to the actual logging classes which  
> will be instantiated? ISTM logging classes are already reasonably  
> usable for programmatic configuration, but this doesn't address e.g.  
> updating configurations easily without program code changes, or the  
> ability to configure from say a YAML node, where YAML may be being  
> used for application configuration as a whole. (Unless of course  
> I've misunderstood what you're getting at.)

The probably are light-weight enough, but I didn't want to assume  
those classes would be used directly.  I suspect they could be, though.

I guess there aren't *so* many levels or keys that the data structure  
will become unwieldy.

Doug