On May 2, 11:29 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> smitty1e <[EMAIL PROTECTED]> writes:
> > Just a fun exercise to unify some of the major input methods for a
> > script into a single dictionary.
> > Here is the output, given a gr.conf file in the same directory with
> > the contents stated below:
>
> > [EMAIL PROTECTED] ~/proj/mddl4/test $ ./inputs.py
> > {'source_db': '/home/sweet/home.db'}
> > [EMAIL PROTECTED] ~/proj/mddl4/test $ source_db="test_env" ./inputs.py
> > {'source_db': 'test_env'}
> > [EMAIL PROTECTED] ~/proj/mddl4/test $ ./inputs.py -f "test_cli"
> > {'source_db': 'test_cli'}
>
> A good start. However, you need to account for two conventions with
> configuration of programs via environment variables:
[snip]
> This is probably best done by a mapping specifically for the
> environment variable names:
>
> config_env_names = {
> 'source_db': 'GR_SOURCE_DB',
> }
>
> and then referencing that dictionary when inspecting the environment:
>
> for key in config.keys():
> # ...
> environ_name = config_env_names[key]
> environ_value = os.environ.get(environ_name)
> if environ_value is not None:
> config[key] = environ_value
> #...
Hmmm...
I kinda think your excellent points are more in the realm of policy
than mechanism.
What I was going for was to assert that there a designated section (of
many possible ones)
in a .conf file that represents the set of possible program inputs,
and then
offering an example of letting environment and command line arguments
override that
.conf section.
Your points for reducing collision are well taken. Possibly having a
removable prefix
(which could be a "magic" .conf entry) would allow for a de-conflictor
prefix like
MY_PROGRAM_REALLY_ROCKSsource_db without having to propagate such an
eyesore throughout
the program code.
In any case, it stands as a fun little worked example.
R,
C
--
http://mail.python.org/mailman/listinfo/python-list
