Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Sun, 2 Aug 2015 16:11:14 -0500
From: Tim Chase <python.list@tim.thechases.com>
To: python-list@python.org
Subject: Re: Most Pythonic way to store (small) configuration
In-Reply-To: <85k2tdlxbg.fsf@benfinney.id.au>
References: <87k2teq9tb.fsf@Equus.decebal.nl> <85k2tdlxbg.fsf@benfinney.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1166.1438566361.3674.python-list@python.org>
Lines: 77
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:94912

On 2015-08-02 21:54, Ben Finney wrote:
> So, both XML and JSON should be considered write-only, and produced
> only for consumption by a computer; they are a poor choice for
> presenting to a human.
>=20
> The =E2=80=9CINI=E2=80=9D format as handled by the Python =E2=80=98config=
parser=E2=80=99 module is
> what I would recommend for a simple flat configuration file. It is
> more intuitive to edit, and has a conventional commenting format.

I second Ben's thoughts against XML & JSON -- they *can* be edited by
hand, but put the onus on the user to make perfect XML/JSON.  Config
files (".ini") are more forgiving.

However, the .ini format (or at least the stdlib implementation in
ConfigParser.py) is not without its faults, mostly when you read a
file, then write it back out:

 - comments and blank lines get lost in the process:

    [section]

    # set to local configuration
    location=3Dpath/to/foo

  will get written out as

    [section]
    location=3Dpath/to/foo
=20

 - the order of options is not preserved:

    [section]
    thing=3D1
    other=3D2

   may get written back out as

    [section]
    other=3D2
    thing=3D1

   though this has improved once ConfigParser started attempting to
   use an OrderedDict by default for internal storage.

 - a single key can only appear once in a section:

    [section]
    option=3Done
    option=3Dtwo

  gets written back out as=20

    [section]
    option=3Dtwo

  - implicit encoding (is it UTF-8, Latin-1, etc?)

When you understand that the underlying internal storage is a dict
(ordered or unordered, depending on availability), a lot of the above
makes sense.  But it still makes me wish for the power of git's
config-file format that seems to preserve original config files much
better.

An additional option is using a sqlite database.  The sqlite
library is part of the stdlib, and advantages include being a single
file, expandability, consistent/reliable character encoding,
cross-platform portability, and atomicity (utilities that read/write
are blocked from getting/creating incomplete data seen by the other
file).

-tkc