On approximately 10/7/2009 10:45 PM, came the following characters from
the keyboard of Vinay Sajip:
Glenn Linderman <v+python <at> g.nevcal.com> writes:
But DictConfigurator the name seems misleading... like you are
configuring how dicts work, rather than how logs work. Maybe with more
context this is not a problem, but if it is a standalone class, it is
confusing what it does, by name alone.
Of course the fully qualified name would be logging.config.DictConfigurator
which does provide the requisite context, but if I think of/someone suggests a
better name I'll certainly use it.
Yes, I suspected it might be something like that, and that does provide
the context, so I'm content. Thanks for verifying it, and the rest is
bikeshedding...
In thinking more about this, I guess I would have the same comment about
the existing fileConfig() API also... it isn't file that is being
configured, but the logs. readConfigFromFile would have been more
descriptive (and lots longer :( ).
Had fileConfig been called "bulkConfig" or "configAll" (these names
attempt to contrast the function of this API versus the individual APIs
that configure one thing at a time) taking a file parameter, then it
could just simply/suddenly also allow a dict parameter, and no new API
would have to be created. Too late for this, however, and with the new
API, it would be possible to deprecate the fileConfig API, and tell the
user to use the ConfigParser (or JSON or YAML or whatever) to create the
dict, and then pass that to DictConfigurator (or bulkConfig or whatever).
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
_______________________________________________
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
