Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Best way to store config or preferences in a multi-platformway.

Reply
Thread Tools

Re: Best way to store config or preferences in a multi-platformway.

 
 
Ivan Illarionov
Guest
Posts: n/a
 
      05-01-2008
On Thu, 01 May 2008 08:30:03 -0500, Nick Craig-Wood wrote:

> Lance Gamet <(E-Mail Removed)> wrote:
>> This project will store most of its actual data in a shared-database,
>> but I have a small amount of user specific data that I need to be
>> stored like configuration or preferences for example, the list of
>> databases that the program should connect to.
>>
>> On Unix this might be a .file, on windows this could be in the
>> registry, or an ini file or an xml file in ProgramData or AppData or
>> something.
>>
>> Is there a pythony way to store such config data, perhaps there is
>> already a standard python package for such a purpose?

>
> I've found
>
> http://docs.python.org/lib/module-ConfigParser.html
>
> To be easy to use and built in. It makes human readable / editable .ini
> - like files.


IMO .ini-like config files are from the stone age. The modern approach is
to use YAML (http://www.yaml.org).

It has a lot of advantages over .ini and xml, YAML syntax was designed to
be easily mapped to Python data types and is very similar to Python.

More at http://en.wikipedia.org/wiki/YAML

As for where to store it, I completely agree with Nick Craig-Wood.

--
Ivan
 
Reply With Quote
 
 
 
 
Carl Banks
Guest
Posts: n/a
 
      05-01-2008
On May 1, 12:11 pm, Jon Ribbens <(E-Mail Removed)> wrote:
> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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.


Carl Banks
 
Reply With Quote
 
 
 
 
Ivan Illarionov
Guest
Posts: n/a
 
      05-01-2008
On Thu, 01 May 2008 11:11:29 -0500, Jon Ribbens wrote:

> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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***.
>
> I certainly wouldn't recommend it as being suitable for, well, anything
> at all.
>
> Or were you trolling and I missed the joke?


No, it isn't. I acually find it usefull and readable. I don't think that
programmers at Google would use something that is a joke.

I used XML files before for this purpose and found YAML much easier and
better suitable for the task.

Please explain why don't like YANL so much?

PS. Your reply remind me of early days of Python when Perl programmers
said exacly the same thing about Python.

--
Ivan


 
Reply With Quote
 
Ivan Illarionov
Guest
Posts: n/a
 
      05-01-2008
On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:

> On May 1, 12:11 pm, Jon Ribbens <(E-Mail Removed)> wrote:
>> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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.
>
>
> Carl Banks


If you don't like YAML, use JSON or something similar -- XML is overkill
and .INI is too limited.

--
Ivan
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      05-01-2008
On May 1, 1:30 pm, Ivan Illarionov <(E-Mail Removed)> wrote:
> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
> > On May 1, 12:11 pm, Jon Ribbens <(E-Mail Removed)> wrote:
> >> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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
 
Reply With Quote
 
tinnews@isbd.co.uk
Guest
Posts: n/a
 
      05-01-2008
Carl Banks <(E-Mail Removed)> wrote:
> On May 1, 12:11 pm, Jon Ribbens <(E-Mail Removed)> wrote:
> > On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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.
>

But XML has human unfriendly syntax, is awkward to type, is difficult
to read, what's good about it? If there's a GUI between you and the
XML then OK, but that wasn't where we were was it?

--
Chris Green
 
Reply With Quote
 
Ivan Illarionov
Guest
Posts: n/a
 
      05-01-2008
On Thu, 01 May 2008 14:13:08 -0500, Jon Ribbens wrote:

> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> wrote:
>> I used XML files before for this purpose and found YAML much easier and
>> better suitable for the task.
>>
>> Please explain why don't like YANL so much?

>
> Because even the examples in the spec itself are unreadable gibberish.
> The PyYAML library is over 300kB! These are rather big clues that it's
> unsuitable for the purpose for which it was designed. It's certainly
> unsuitable for use as a configuration file format, where it is overkill
> by several orders of magnitude.
>
> !!str &a1 "foo":
> !!str bar
> &a2 baz : *a1
> !<tag:yaml.org,2002:str> foo :
> !<!bar> baz
>
> This is supposed to be human readable?


Thanx, now I see your point. I didn't mean all the fancy features of
YAML, but the most basic sintax.

Compare this:
<user id="babooey" on="cpu1">
<firstname>Bob</firstname>
<lastname>Abooey</lastname>
<department>adv</department>
<cell>555-1212</cell>
<address password="xxxx">(E-Mail Removed)</address>
<address password="xxxx">(E-Mail Removed)</address>
</user>

and this:
babooey:
computer : cpu1
firstname: Bob
lastname: Abooey
cell: 555-1212
addresses:
- address: http://www.velocityreviews.com/forums/(E-Mail Removed)
password: xxxx
- address: (E-Mail Removed)
password: xxxx

I find the latter *much* more readable.

And the most important thing is that it *maps directly to Python data
types*, in this case dictionaries and lists:
{babooey: {computer: cpu1, firstname: Bob, lastname: Abooey, cell: 555,
1212, addresses: [{address: (E-Mail Removed), password: xxxx},
{address: (E-Mail Removed), password: xxxx}]}

I took the example from
http://www.kuro5hin.org/story/2004/10/29/14225/062
I haven't use my own example only because I don't have one at hand right
now. YAML, in its simple form, definetely makes me more productive. I
wasted too much time with XML in the past and I won't ever use it as a
serialization or config/settings format again. .INI/ConfigParser is too
limited and has no standards. I just don't see anything better than YAML
to do human and Python editable config files and to serialize information
for later use.

>> PS. Your reply remind me of early days of Python when Perl programmers
>> said exacly the same thing about Python.

>
> I think I would suffer irony overload if I saw a Perl programmer
> criticising Python for being hard to read

 
Reply With Quote
 
Ivan Illarionov
Guest
Posts: n/a
 
      05-01-2008
On Thu, 01 May 2008 11:56:20 -0700, Carl Banks wrote:

> On May 1, 1:30 pm, Ivan Illarionov <(E-Mail Removed)> wrote:
>> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
>> > On May 1, 12:11 pm, Jon Ribbens <(E-Mail Removed)> wrote:
>> >> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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. 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.

--
Ivan
 
Reply With Quote
 
Ivan Illarionov
Guest
Posts: n/a
 
      05-01-2008
On Thu, 01 May 2008 23:03:38 +0200, Torsten Bronger wrote:

> Hallöchen!
>
> Ivan Illarionov writes:
>
>> [...]
>>
>> I took the example from
>> http://www.kuro5hin.org/story/2004/10/29/14225/062 I haven't use my own
>> example only because I don't have one at hand right now. YAML, in its
>> simple form, definetely makes me more productive. I wasted too much
>> time with XML in the past and I won't ever use it as a serialization or
>> config/settings format again. .INI/ConfigParser is too limited and has
>> no standards. I just don't see anything better than YAML to do human
>> and Python editable config files and to serialize information for later
>> use.

>
> Okay, but serialisation is something completely different. Nobody would
> use INI files for it.
>
> For other things, it simply depends on the use case. For example, I
> *know* that the configuration files of my pet project will not exceed
> the dumb section.key=value scheme so anything else would be overkill.
>
> Besides, YAML adds another dependency.
>
> Tschö,
> Torsten.


For me it looks more like an old-school/new-school thing than use-case
thing. I may be wrong, but I see more and more new projects use things
like reST and YAML/JSON and it feels like they are gradually replacing
traditional old-school solutions.

And I've got very strong impression that YAML is a the future of
configuration files when Google released their App Engine.

Of course I may be wrong and it's just my opinion.

--
Ivan

 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      05-01-2008
On May 1, 4:50 pm, Ivan Illarionov <(E-Mail Removed)> wrote:
> On Thu, 01 May 2008 11:56:20 -0700, Carl Banks wrote:
> > On May 1, 1:30 pm, Ivan Illarionov <(E-Mail Removed)> wrote:
> >> On Thu, 01 May 2008 09:45:28 -0700, Carl Banks wrote:
> >> > On May 1, 12:11 pm, Jon Ribbens <(E-Mail Removed)> wrote:
> >> >> On 2008-05-01, Ivan Illarionov <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Set java.util.logging.config.file via the Preferences API. Robert Mark Bram Java 0 04-30-2007 02:44 PM
dll config and web.config and Label Expressions (binding label text to dll config settings) CSharpner ASP .Net 0 04-09-2007 09:00 PM
Best way to store a time? Tarun Mistry ASP .Net 1 02-22-2006 12:33 PM
Best way to store a large number of files? heather.fraser@gmail.com Java 13 10-10-2005 01:11 PM
Best way to load/store web site settings in database Max ASP .Net 2 12-08-2003 10:39 PM



Advertisments