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

[Ivan Illarionov]

On Thu, 01 May 2008 16:32:00 -0700, Carl Banks wrote:

> 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.

Agree, all depends on programmer's preferences.

> 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

No, all I want is to give the OP a useful alternative and make him aware 
of the latest trend in the config file formats.

-- 
Ivan