Python noob's simple config problem

[kj]

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

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[=?iso-8859-1?q?Robin_K=E5veland?= Hansen]

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.

[kj]

In <g2*********@ku ling.itea.ntnu. no=?iso-8859-1?q?Robin_K=E5v eland?= Hansen <ka*******@gmai l.comwrites:

>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
configuratio n 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.