Best way to store config or preferences in a multi-platform way.

[Carl Banks]

On May 1, 4:50 pm, Ivan Illarionov <ivan.illario... at gmail.com> wrote:
> On Thu, 01 May 2008 11:56:20 -0700, Carl Banks wrote:
> > On May 1, 1:30 pm, Ivan Illarionov <ivan.illario... at gmail.com> wrote:
> >> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
> >> > On May 1, 12:11 pm, Jon Ribbens <jon+use... at unequivocal.co.uk> wrote:
> >> >> On 2008-05-01, Ivan Illarionov <ivan.illario... at gmail.com> wrote:
>
> >> >> > IMO .ini-like config files are from the stone age. The modern
> >> >> > approach is to use YAML (http://www.yaml.org).
>
> >> >> You mean YAML isn't a joke!? It's so ludicrously overcomplicated,
> >> >> and so comprehensively and completely fails to achieve its stated
> >> >> main goal of being "readable by humans", that I had assumed it was
> >> >> an April Fool along the lines of Intercal or brainf***.
>
> >> > YAML, ISTM, took a simple concept that worked for small,
> >> > straightforward data, and tried to make into a format that could
> >> > anything anywhere, with disastrous results.  It's not unlike Perl in
> >> > this regard.  It's quite ridiculous.
>
> >> > My recommendation to the OP would be:
>
> >> > If you intend to write a GUI that completely sets all the options,
> >> > use XML.  You can bet there are some users who would prefer text
> >> > editing options files, and XML, while not the most readable format
> >> > available, at least gives users the option.
>
> >> > If you don't intend to write a GUI to do that, write a simple text
> >> > file parser (if the options are simple), use ConfigParser, or use a
> >> > Python file that you exec.
>
> >> > Store the file in $HOME/.appname/config.ext on Unix, $USERDIR/
> >> > ApplicationData/Appname/config.ext on Windows.  I don't recommend
> >> > using the Windows registry to store options; use it to modify Windows
> >> > behavior (like file associations) but keep your own program's options
> >> > in your own file.
>
> >> If you don't like YAML, use JSON or something similar -- XML is
> >> overkill and .INI is too limited.
>
> > I don't think you know the OP's requirements enough to know whether INI
> > or XML is suitable. You're welcome to suggest alternatives but what I
> > suggested is fine.
>
> > As for XML being overkill for anything, I highly disagree. XML is
> > suitable for the smallest tasks.  These days I use XML for almost all my
> > data exchange needs: including conf files.  Elementtree makes it
> > possible to process XML and pull out some typical data in ten or so
> > lines of code.  What could possibly be overkill about that?
>
> > Carl Banks
>
> I used XML for almost everything in the past until I found YAML.
> Elementtree makes it easy but not easy enough.

I'm honestly very happy for you that you have found the data transfer
format that you are happy with, but I'm sorry, that doesn't amount to
a blanket invalidation of everything you've ever tried and rejected.


> The most powerful thing
> about YAML is that it was designed to map directly to native data types
> in languages like Python (see another my post in this thread for
> example). And this means that simple YAML files will always be easier to
> process in Python than XML or INI. And this in turn means that OP with
> any requirements will have to write less code to read and write his
> config files.

I will mention that Python already has, built in, a data transfer
format that maps directly to Python types: pickle.

And not only that, it's more readable than YAML.


I will also add that what you think of as a strength is not always
thought of as a strength by everyone.  In my early days of Python, I
would use pickle for all kinds of things.  I've now pretty much
switched entirely to XML, because I no longer believe that direct
correspondance to Python types is a good thing; at least it isn't for
me.  There is a very basic reason for this: whenever I write a pair of
tools, one to output some XML data, and another further down the chain
to read it back in, I hardly ever want the data to have the same
structure in memory in both tools.  For me, YAML or pickle would not
gain me anything; I'd be doing all that reformatting anyway.


Of course, the OP wasn't talking about data transfer, he was talking
about a freaking config file.  Reading in a config file is a
ridulously silly thing to try to hyperoptimize.  Do you really want
him to add an extra dependency just to reduce code used by five lines?


Carl Banks