data design

[Szabolcs Nagy]

> The lazy way to do this: have modules that initialize bunches of
> objects, attributes holding the data: the object is somehow the row of
> the "table", attribute names being the column. This is the way I
> proceeded up to now.
> Data input this way are almost "configuration data", with 2 big
> drawbacks:
>   - Only a python programmer can fix the file: this cant be called a
>     configuration file.
>   - Even for the author, these data aint easy to maintain.
>
> I feel pretty much ready to change this:
> - make these data true text data, easier to read and fix.
> - write the module that will make python objects out of these data:
> the extra cost should yield ease of use.
>
> 2 questions arise:
> - which kind of text data?
>      - csv: ok for simple attributes, not easy for lists or complex
>      data.
>      - xml: the form wont be easier to read than python code,
>        but an xml editor could be used, and a formal description
>        of what is expected can be used.
> - how can I make the data-to-object transformation both easy, and able
>    to spot errors in text data?
>
> Last, but not least: is there a python lib implementing at least part
> of this dream?

there is a csv parser and multiple xml parsers in python (eg 
xml.etree) also there is a ConfigParser module (able to parse .ini 
like config files)

i personally like the python module as config file the most

eg if you need a bunch of key-value pairs or lists of data:
* python's syntax is pretty nice (dict, tuples and lists or just 
key=value)
* xml is absolutely out of question
* csv is very limited
* .ini like config file for more complex stuff is not bad but then you 
can use .py as well.