On Mon, 30 Mar 2009 16:59:12 +0100, jfager <jfa...@gmail.com> wrote:
It's the configuration problem. Right now you would use something like ConfigParser or optparse to populate some configuration object, which you would then pass around and extract values from. This would provide two advantages over these approaches: it would separate "what can be configured" from "the mechanism by which it is configured" - i.e., I, programmer, don't have to make a decision about what the end user has to do to give me those values.
This would be a interesting idea, but ultimately no more than a veneer over the current set of configuration possibilities. Quite how such a system would tell whether to get configuration data from command line parameters, a config file somewhere, or just pull bytes off the Z-wave from Mars, I'm not at all clear.
And it would allow the configurable surface of the program to be discoverable; I wouldn't have to poke through code or documentation that was maintained separate from the source code.
Except that you still do. You've just specified a different way in which you have to do this, one that's a good deal less visible in the code and a lot less self-documenting because it's spread out all over the place. It also has the major disadvantage from my point of view of requiring Python to do magic in the background to figure out just what is being configured. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
