In <[EMAIL PROTECTED]> =?iso-8859-1?q?Robin_K=E5veland?= Hansen <[EMAIL PROTECTED]> writes:
>On Thu, 12 Jun 2008 21:32:34 +0000, kj wrote: >> I'm sure this is a simple, but recurrent, problem for which I can't hit >> on a totally satisfactory solution. >> >> As an example, suppose that I want write a module X that performs some >> database access. I expect that 99.999% of the time, during the >> foreseeable future, the database connection parameters will remain >> unchanged. The only exception that I envision for this would be during >> testing or debugging. >> >> Given all this, I am tempted to turn these connection parameters into >> hard-coded module attributes that I can always override (i.e. overwrite) >> when necessary. >> >> But for as long as I can remember the dogma has been that hard-coded >> values are bad, and that one should use other techniques, such as >> configuration files, or parameters to a suitable constructor, etc. >> >> This is where I begin to get confused: whose responsibility is it to >> know of and read the config file? I can think of two distinct >> scenarios: 1) module X is being used by a large, full-fledged >> application A that already uses a config file for its own configuration; >> 2) module X is being used by a simple script that has no need for a >> config file. In case 1 I'd be glad to let application A set module X's >> connection parameters using values read from its own (i.e. A's) config >> file; this minimizes the number of config files that need to be >> maintained. In case 2, however, it would be preferable for module X to >> read its connection params from its own (i.e. X's) config file. In this >> way the script won't have to bother setting some parameters that are in >> fact practically constant... >> >> After going round and round on this, my original idea of hard-coding the >> values as module attributes begins to look pretty attractive again. >> >> How would you handle such situations? >> >> Thanks! >> >> kynn >I think I would just abstract it away with a "getter" for the connection, >a function that takes some optional parameters, if not supplied, it >simply fetches them from a default configuration. Ie: >def connect(params=None): > if params is None: > return dblayer.connect(conf["default"]) > else: > return dblayer.connect(params) >Unless I have misunderstood you completely? Now people can change your >scripts config file, and if someone wants to use your code, they can use >the getter directly. >I hope this is of some help. Thanks! Kynn -- NOTE: In my address everything before the first period is backwards; and the last period, and everything after it, should be discarded. -- http://mail.python.org/mailman/listinfo/python-list
