[Python-Dev] A new way to configure logging
Doug Hellmann
doug.hellmann at gmail.com
Thu Oct 8 18:00:35 CEST 2009
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
More information about the Python-Dev
mailing list