[Tutor] I Give Up. - Follow up post

[Brian Gustin]

> 
> The other alternative is to provide a tool for editing the file in which
> case the format is less important sionce hiumans "never" need to
> touch it.
> 
Heh. good analysis.. now I feel a little dumb- I should have thought of 
this *LONG* ago. yeah I knew about the xml parser , and how to do xml 
markup (it's one of the methods we use on intranet communications 
channels for certain scriptable tasks) ...

My sticking point was, I wanted it to be super easy for a newbie or 
beginner or "sysadmin trainee" to install and set up the monitoring 
without needing to know much more than maybe basic command line..

That's when it finally hit me (thanks to your commentary below) , why 
use a config file at all? all I have to do is create a simple "setup" 
utility that will write the "configuration" data I need in *correct and 
perfect* python syntax, which I can simply reload, or re-import into the 
daemon ... no need to even have a text editor, all I need is a little 
shell script or python utility to ask for and wait for the user's input 
at each prompt, and check data at each step to get it right..

Yep, I think I was *absolutely* over-thinking the issue here. :)

> How about command line tools?
> Somewhat like the commonly found adduser command in Unix?
> 
>>>> Yeah, basically you carry values in a dictionary named by keyname , 
>>>> but..  there have been situations where I need the key name as the 
>>>> variable name , I.E. config_options[name] = value could become
>>>>
>>>> name = value as if it was explicitly defined that way
> 
> 
> While I understand the usefulness of this in an interactive environment
> I'm puzzled about how this would work in a pre-written script. If you are
> creating variables from a config file how do you know what those variables
> are called? If you don;lt know how can you reference them later in the
> code? And if you don;t reference them of what value is the variable
> name? Therefore the logical conclusion(to me!) is that you must
> know what names you expect to read and therefore can use a dictionary?
> 
> I'm not sure I understand where exactly you are having the problems
> (other than the admnittedly poor configparser documentation! - the
> quality of python docs tends to be directly proportional to its frequency
> of use and inversely proportional to age - more recent modules tend to
> be better documented than ancient ones. Unfortunately for you config
> parser doesn't seem to be used that much and has been there for ever!)

Yeah this kind of confused the whole issue- and snowballed a little 
bit.. got off track ..

Point originally was, I wanted to be able to read in a config file as a 
name => value pair , and then actually have a variable named by name in 
the script, which you cannot do using a dictionary, you could use the 
key, yes, but at the time it didnt make sense to me to have 4 or 5 
dictionaries laying around in memory when they only have one or two keys 
, and I wanted to use single variables..

Comes from wanting to minimize how much stuff I have loaded into memory, 
and my impression is, a dictionary of 2 elements (name:value pairs)
takes up more space in memory than two single variables (name points to 
value in memory), and the conversation just ultimately got mixed up, and 
I couldnt even remember, in the end why I needed the variable names Vs. 
a dict, until I went back to SubVersion and dug out the first 2 versions 
of my code :)

(Got to love Revision control systems! )

Anyhow, that's now a moot point. :) I have no valid reason at this point 
to insist on knowing variable names.

However to make a point, my original thinking was along the lines of a 
way to do variable variables, (there are certain instances where they 
can be handy) , however since python has no $ to start a variable, I saw 
no way it was possible... Oh well

I have yet to get back in this project, it's working as needed in Perl 
(with a somewhat kludgy configuration, and really, IMHO, more code than 
is really necesary for something so simple as this) but it does the job, 
and I have other things I must do :)

> 
> HTH,
> 
> Alan Gauld
> Author of the Learn to Program web site
> http://www.freenetpages.co.uk/hp/alan.gauld
> 
> 
> !DSPAM:44ab7d4d293088057919449!
> 
>