New configuration module released

[Vinay Sajip]

Dan Perl wrote:

> 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.

OK, but I'm not sure that completely unrestricted Python code in 
configurations is the way to go. It certainly makes it more likely that 
a developer will put things in the configuration which an end user can 
inadvertently break. If it's pure Python in the configuration, it's 
possible that the breakage will cause more damage than where a 
Python-like syntax is parsed.

> 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 may not be important to you, but that's one reason why XML is so 
popular: data can be shared across platforms more easily.

> 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?

It's certainly possible, but very verbose for both reading and writing, 
and more error-prone if end-users can change configuration files. It's 
easy to make an XML file ill-formed through simple typing errors, like 
forgetting the / to terminate an empty tag - even experienced developers 
do this. Sometimes an XML parser can report the error several lines 
further down, depending on the DTD/schema being used.

> 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.

I only gave a simple example to illustrate possibilities. There's no 
reason why you couldn't do this with a more dynamic structure - that's 
the province of your program, not the config module.

> 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.

Great.

> 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

The problem I see is that everyone's idea of metadata will be different. 
  If you have strong and rigorous requirements in this area, the rigour 
of XML and XML schema may be what you need. It's not a goal of the 
config module to be all things to all people - it's meant to remain 
reasonably simple while still providing useful functionality, enough to 
supplant ConfigParser for those who need it.

Best regards,


Vinay Sajip