Most Pythonic way to store (small) configuration

Tim Chase python.list at tim.thechases.com
Sun Aug 2 23:11:14 CEST 2015


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.
> 
> The “INI” format as handled by the Python ‘configparser’ 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=path/to/foo

  will get written out as

    [section]
    location=path/to/foo
 

 - the order of options is not preserved:

    [section]
    thing=1
    other=2

   may get written back out as

    [section]
    other=2
    thing=1

   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=one
    option=two

  gets written back out as 

    [section]
    option=two

  - 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






More information about the Python-list mailing list