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
_______________________________________________
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
