Most Pythonic way to store (small) configuration

[Cameron Simpson]

On 04Aug2015 19:32, Michael Torrie <torriem at gmail.com> wrote:
>On 08/04/2015 01:59 PM, Ben Finney wrote:
>> marco.nawijn at colosso.nl writes:
>>> Why not use Python files itself as configuration files?
>>
>> Because configuration data will be user-editable. (If it's not
>> user-editable, that is itself a poor design choice.)
>>
>> If you allow executable code to be user-edited, that opens your program
>> to arbitrary injection of executable code. [...]
>
>We need to state the context here.  The only context in which having a
>Python config file is dangerous is when the python program runs as a
>different user/privilege than the owner of the config file.  If the user
>owns the python files as well as the config file then none of this matters.
[...]
>If I'm talking about a system service that is doing things for non-root
>users, then yeah I'll agree with your argument completely.  But not for
>most other situations.  Even a system service, if the config file is
>owned by root, I'm okay with using python as configuration. [...]
>In fact python as configuration works very well for my purposes, and it
>works well for Django, and there are many other projects that also do
>this.  I don't think you'd want to use any other mechanism for
>configuring Django, frankly.  I'm a bit surprised no one has mentioned
>Django in this discussion yet. [...]

Django crossed my mind as well, but my take is very different. I'm of two minds 
on Django's use of Python files for config.

On the one hand it is very flexible, it can express 
comoplicated/subtle(/fragile?) setups as needs and, if you are writing the 
Django app instead of just using it, it is in the same language as the app.

On the other hand, if you want to consult that config from _outside_ the app 
with another tool not necessarily written in Python you're screwed. Many things 
can read a .ini file. Very few things can read arbitrary Python code, and any 
that can _must_ expose themselves to whatever that code may do. If the 
consulting code is in a different security context (system config monitors, 
admin scripts, etc) then we're back in the risk zone.

So on the whole I am against python code as the config file format. Really, who 
needs a Turing complete configuration file?

Go with something simple, both in syntax and semantics. It is easier to read, 
easier to write/modify, and easier to access from multiple tools.

Cheers,
Cameron Simpson <cs at zip.com.au>

A protocol is complete when there is nothing left to remove.
- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking