On approximately 10/7/2009 7:49 AM, came the following characters from
the keyboard of Vinay Sajip:
> In outline, the scheme I have in mind will look like this, in terms of the new
> public API:
>
> class DictConfigurator:
> def __init__(self, config): #config is a dict-like object (duck-typed)
> import copy
> self.config = copy.deepcopy(config)
>
> def configure(self):
> # actually do the configuration here using self.config
>
> dictConfigClass = DictConfigurator
>
> def dictConfig(config):
> dictConfigClass(config).configure()
>
> This allows easy replacement of DictConfigurator with a suitable subclass where
> needed.
Concept sounds good, and the idea of separating the syntax of the
configuration file from the action of configuring is a clever way of
avoiding the "syntax of the (day|platform|environment)" since everyone
seems to invent new formats. So people that want to expose a text file
to their users have the choice of syntaxes to expose, and then they do
logCfg = readMyFavoriteSyntax( logCfgFile )
# or extract a subset of a larger config file for their project
DictConfigurator( logCfg )
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.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4