> 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.
 
> 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.)

Regards,

Vinay Sajip



      
_______________________________________________
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

Reply via email to