data design

[James Stroud]

Szabolcs Nagy wrote:
>>Hurray for yaml! A perfect fit for my need! And a swell tool!
>>Thanks a lot!
> 
> 
> i warn you against yaml
> it looks nice, but the underlying format is imho too complex (just 
> look at their spec.)
> 
> you said you don't want python source because that's too complex for 
> the users.
> i must say that yaml is not easier to use than python data structures.
> 
> if you want userfriedly config files then ConfigParser is the way to 
> go.
> 
> if you want somthing really simple and fast then i'd recommend s-
> expressions of lisp
> 
> also here is an identation based xml-like tree/hierarchical data 
> structure syntax:
> http://www.scottsweeney.com/projects/slip/
> 

I've been spending the last 2 days weighing ConfigParser and yaml, with 
much thought and re-organizing of each file type. The underlying 
difference is that, conceptually, ini files are an absurdly limited 
subset of yaml in that ini files are basically limited to a map of a map.

For instance, I have a copy_files section of a configuration. In order 
to know what goes with what you have to resort to gymnastics with the 
option names

[copy_files]
files_dir1 = this.file that.file
path_dir1 = /some/path

files_dir2 = the_other.file yet_another.file
path_dir2 = /some/other/path

In yaml, it might look thus.

copy_files :
      - files : [this.file, that.file]
        path  : /some/path
      - files : [the_other.file, yet_another.file]
        path  : /some/other/path

Both are readable (though I like equals signs in appearance over 
colons), but yaml doesn't require a lot of string processing to group 
the files with the paths. I don't even want to think the coding 
gymnastics required to split all of the option names and then group 
those with common suffixes.

Now if the config file were for copying only, ini would be okay, because 
one could just have sections that group paths and dirs:

[dir1]
files = this.file, that.file
path = /some/path

[dir2]
...

But if you need different kinds of sections, you have outgrown ini.

In essence, ini is limited to a single dictionary of dictionaries while 
yama can express pretty much arbitrary complexity.

James