New configuration module released

[Dan Perl]

"Vinay Sajip" <vinay_sajip at red-dove.com> wrote in message 
news:mailman.5876.1099519315.5135.python-list at python.org...
>> First, some small issues.  The syntax for your configuration is still 
>> fairly close to the python syntax and it involves quite a bit of learning 
>> for both python users and non-python users.  Your module would save me a 
>> little bit of work in parsing when loading a configuration (remember, I 
>> am loading configurations by importing them as a module) and a little 
>> more work than that in formatting when saving a configuration.  That work 
>> is not very significant though and having my own mechanism also has its 
>> advantages.
>
> One important benefit of having Python-like syntax is that it is easy to
> create a configuration programmatically, using just dicts and lists.
> This is something that you cite below as a big issue for you.
>
> In terms of learning - I'm not sure that python developers would have
> any real problem with the basic syntax. For end users, it's a case of
> unfamiliarity rather than intrinsic difficulty, IMO.

You're right, but my point is that for python programmers it's even better 
if the configuration is implemented in plain python instead of using a 
python-like syntax.  As for non-python programmers, which is where my 
biggest concern was, both solutions are an inconvenience.

As for creating a configuration programmatically, I can do that using python 
for the syntax (and I am already doing that).  Your syntax is better for 
other, non-python applications that may also be interested in using these 
configuration mechanism, but that is not important for me.  Besides, 
non-python applications would still have to implement their own parsing and 
formatting for this syntax.

It's just an idea and I haven't put a lot of thought in it myself, but what 
about using XML for the configuration syntax?

>> Now, here is the biggest issue I have and what I would be extremely 
>> interested in seeing in a configuration module.  I don't see from your 
>> documentation how I could programmatically create a configuration from 
>> scratch.  In my project I have a set of handlers and each handler has a 
>> special configuration.  Each such special configuration is defined by a 
>> structure of metadata (with information like name, type, description) 
>> that I implemented myself.  That way, my GUI tool can load a handler 
>> dynamically, read its configuration metadata, dynamically create a frame 
>> for the handler's configuration, and save the new configuration to a 
>> file.
>
> There are many ways you could do what you want to do. Without knowing
> the details of your application, I can't give particularly good advice.
> However, consider the following program:
>
> from config import Config
> from cStringIO import StringIO
>
> root = { }
> messages = [ ]
> root['total_period'] = 100
> root['test'] = True
> root['another_test'] = False
> root['yet_another_test'] = None
> root['messages'] = messages
> root['message'] = 'Hello, world!'
> messages.append({ 'message' : 'Welcome', 'name' : 'Harry' })
> messages.append({ 'message' : 'Welkom', 'name' : 'Ruud' })
> messages.append({ 'message' : 'Bienvenue', 'name' : 'Yves' })
>
> stream = StringIO()
> print >> stream, root
> value = stream.getvalue()
> stream.close()
>
> stream = StringIO(value[1:-2])
> cfg = Config(stream)
> cfg.save(file('test.txt', 'w'))
>
> This shows how easy it is to programmatically construct a simple
> configuration from scratch.

I probably didn't express clearly enough what I need in my initial posting. 
Your example is for a statically defined configuration structure.  I am 
interested in a configuration structure that can be defined dynamically.  So 
if I load a plugin with a configuration structure that I don't know 
beforehand, I can still create that configuration programmatically.

> It would be easy for your configuration to hold a separate tree in the
> configuration with the metadata. For example, you could construct a GUI
> frame given a set of fields:
>
> fields: [ title, firstname, surname, age, jobtitle ]
> metadata: {
>     title : { description: 'Salutation', type: choice,
> values: [ [1, 'Mr.'], [2, 'Mrs.']] }
>     firstname : { description: 'First name', type: text,
> max_length: 20 }
>     surname : { description: 'Last name', type: text, max_length: 20 }
>     age : { description: 'Age', type: int }
>     jobtitle: { description: 'Job title', type: text }
> }
>
> Then you can easily loop through the fields.
>
> from config import Config
>
> cfg = Config(file('metadata.cfg'))
>
> for fld in cfg.fields:
>     metadata = cfg.get('metadata.' + fld)
>     print "name = %r, type = %r, description = %r" %
>          (fld, metadata.type, metadata.description)
>
> with the result
>
> name = 'title', type = 'choice', description = 'Salutation'
> name = 'firstname', type = 'text', description = 'First name'
> name = 'surname', type = 'text', description = 'Last name'
> name = 'age', type = 'int', description = 'Age'
> name = 'jobtitle', type = 'text', description = 'Job title'

This is a great idea and it's very useful for me: defining the metadata as a 
configuration file.  And your configuration module could be useful for that. 
Thanks.  I will consider it.

And yet, I would still like to see a generic mechanism for configuration 
metadata.  And this is the point where I expected to see a discussion.  Am I 
the only one seeing a need to define configuration structures with metadata? 
I see that useful for:
   - dynamically defined configurations like in my project
   - sharing the same configuration structure between several applications, 
so
     for instance a configuration created by one application can be used by
     another application

Any opinions on that?

Dan

> I hope the above allows you to see the potential that the config module
> has to meet your needs.
>
> Best wishes,
>
>
> Vinay Sajip
>
>