data design

[Imbaud Pierre]

James Stroud a écrit :
> Szabolcs Nagy wrote:
> 
>>> Hurray for yaml! A perfect fit for my need! And a swell tool!
>>> Thanks a lot!
>>
>>
>>
>> i warn you against yaml
I feel both thanful, and sorry, for your warning. And not convinced
yet, but Ill be cautious.
>> it looks nice, but the underlying format is imho too complex (just 
>> look at their spec.)
complex indeed, but real powerful.
Is it not true that: if I used yaml, sticking to what .ini allows,
yaml files would be simple?
>>
>> 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.

Easier to read and write, U must agree.
Surround strings with quotes is a python requirement, to distinguish
them from identifiers. This only makes data input for python somewhat
clumsy.
Granted, its a new format to learn. But sharing this format with a
much wider community than python, aint this worth the effort?
(well, if yaml succeeds and spreads...)
>>
>> if you want userfriedly config files then ConfigParser is the way to go.
Granted. for END users. I rather target administrators, programmers,
integrators: make customization an easy process, and allowing this
customization to go much farther than changing simple values, aint
this the REAL challenge for new applications?
>>
>> if you want somthing really simple and fast then i'd recommend s-
>> expressions of lisp
lisp is more powerful than python. its syntax deterred many
programmers, who adopted python, it will deter my targeted
"customizers". And the process to translate to python structure, I
have no idea. involves a python or lisp translater...
>>
>> also here is an identation based xml-like tree/hierarchical data 
>> structure syntax:
>> http://www.scottsweeney.com/projects/slip/
Pretty nice, too! James, have a look at this!
>>
> 
> 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.
U have a point here.
> 
> 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, this single formula makes things real clear.
As we both work on the subject, maybe we could continue to exchange
ideas, and information?
Have a look at the link Szabolcs Nagy <nszabolcs at gmail.com> gives:
http://www.scottsweeney.com/projects/slip/
Ill further dig yaml, with 2 questions:
- how do I translate to python?
- how do I express and/or enforce rules the data should follow?
   (avoid the classic: configuration data error raise some obscure
   exception).

Big thanks to Szabolcs Nagy (hungarian, my friend? I love this
country), although I seem to disagree, your statements are pretty
clear and helpful, and... maybe U are right, and I am a fool...
Pierre