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
--
http://mail.python.org/mailman/listinfo/python-list
