python parser for dotconf file

[Hynek Hanke]

Hello Hermant,
>
>    1. Would the dotconf project benefit from a generic python program
>       that allows to read/editparameters within a dotconf file?
>
I can't speak for DotConf, but Speech Dispatcher would surely benefit.

I'm now working on a simple python tool that would guide
the user through basic configuration and problem diagnosis
after installing Speech Dispatcher (for example creating
configuration in ~/.speech-dispatcher, diagnostics if festival-server
is ready to work for Speech Dispatcher or a possibility
to automatically generate all necessary speechd logs and send
them to us for diagnosis as a last resort). For that purpose,
I also need to modify the dotconf configuration files programatically,
so I would really welcome such a library.
>
>    1. How to modify the parameter values when multiple instances of
>       the same parameter exist as describred above.
>
When there are several lines with the same parameter name,
this should be treated as an enumeration or a list. For example
,,AddModule'' is used to construct a list of modules to be loaded.

So I think that the only reasonable way to modify them is to read
all such options first, construct the list, then modify it and write
back. I don't think it makes sense to modify them separately.

> For your reference I am attaching the pyDotconf project that I created.
I've tried it, it seems to work well and the code is very clear.

One possible issue I can see with the DotConf configuration file
is how to distinguish between an option that is commented out
and a commentary (text) beginning with the option name.

Like in this case:
# DefaultModule is the module that will be used by default
# DefaultModule "festival"

We might make a rule that description comments are not
allowed to begin with an option name in the configuration file.
I would then change the config files in the next release of Speech
Dispatcher so that this doesn't happen. Users however have
older configuration files around, so this case should be handled
somehow (I would say that if after stripping the comment character,
the line doesn't make a proper dotconf syntax, it should be
treated as a text coment).

I have a question. Are you also planning to develop some tool
to set the configuration option or are you going to use the python
library for use in some OLPC-specific configuration mechanism?
I'd like to learn more, because it looks interesting.

With regards,
Hynek Hanke