>> ####################################
>> ### machine_config.py
>> machines = { 'apache': ('http', 80),
>>              ## fill me in with the config of other machines
>> }
>> ####################################
>>
>> could be used as your configuration file format.  The value portion 
>> of a

> Umm well it would work nicely . *if* the configuration never 
> changed- on the other hand, if it is to do as intended, the user of 
> the application needs to be able to add and edit the configuration.

Ok, would an XML format work better? There are several good XML
parsers available.

<machine name='apache'>
    <protocol name = 'http'>
        <port=80/>
    </protocol>
    <protocol name='smtp'>
      etc...
</machine>

or something similar?

> it is easier for a non programmer to edit a configuration that makes 
> some sort of logical sense and is easy to edit, without screwing up 
> (need to make it more "forgiving" of things like line endings, 
> spacing between name , = and value elements, etc)

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.

>>> believe me I have tried dictionaries, Ive tried parsing the file 
>>> by other means, but the only way I could get results I needed was 
>>> through configparser

If you are using ini file format config parser is the right choice.
But there are other file formats and making the data match the
problem is usually the biggest breakthrough in creating clean code.
So although ini format might be simplest to maintain by non technical
users if it forces you to ju7mp through hoops mayber a slihghtly more
complex format would be better.
(An example is the XF86 setup file used in Linux which uses a
syntax somewhat like a Python dictionary mixed with an ini file)

> Another option I had was to do a web based interface for setting up 
> additional machines, etc, but web based is non-ideal for this 
> application.

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?

Typically the examples I've seen are where people use a known
name as the root and append a sequence number:

foo1 = 43
foo2 = 45
etc

then they use a loop later in the code to reconstitute the variable 
names.

But if a list is used inside a dictionary the same effect is achieved 
with
about the  same or less work:

vars['port'].append(42)
vars['port'].append(45)
for port in vars['port']:
    use port here.

The other scenario that often arises is that you know the variable 
names
you expect to find and only use those names, thus if a user causes
an unexpected name you just ignore it.

In this case you can create a dictionary of the known variable names
for validation purposes and link them to a set of helper functions 
(one
per variable) for storing the values in your variables:

Something like this:

machine = []  # list variable
port = None   # scalar value

def addMachine(value): machine.append(value)
def addPort(value):
     global port
     port = int(value)

vars = {'machine':addMachine,'port':addPort}

name = parseConfig()
if name in vars.keys():
    vars[name](parseConfig())

And if you don't like the helper functions you could use lambdas:

vars = {'machine':  lambda val: machine.append(val),
           'port':        lambda val: port = int(val)
          }

One you finish parsing the data you can now use machine and
port as normal variables, since that's what they are.
(Note: by converting the string value to an int I remove the issue
of extraneous spaces. Not a universal cure but a step forward)

>> Can you show us the situation you're talking about that requires 
>> this?

I'm not sure the stuff above actually addresses what you need,
but it might give some ideas? Like Danny I'd like to see an example
where the dictionary approach wouldn't work.

> Sure, I could also do this by reading a config file and parsing it , 
> but ..
>
> Say you split at the = , and the config file is like
>
> http = 80 #standard http port
>  https=443#https port
>
> Are you going to be 100% certain that when you call 
> watch_hosts[http], that you are gonna GET string "80"?
>  what about the space between http and =  ?

Yes, user errors like added spaces, mixed case, dropped or wrong
syntax(semi-colons/colons etc) are perennial problems and why a
pre-written parser is the best approach if you can finfd one that fits
your need. But it looks like maybe config parser is just a bit too
simplistic for the data you are trying to manage?

> I just didnt see any more effective way to get this than to use 
> ConfigParser as opposed to attempting to parse a file using regular 
> expressions , trim, split, etc

Python does support other data types including CSV and XML.
Maybe one of those can give you what you want more easily?

>>> It's difficult to grasp or even effectively explain the concept or 
>>> idea,
>>
>> Try to do so.  I think this is a real point that needs to be 
>> cleared up.
>
> I understand the concept/idea behind it, I think above is about as 
> good an explanation as it gets

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!)

HTH,

Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld 


_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to