Python Forum

Full Version: configuration formats / languages
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
when you create an application that needs or offers user and/or system-wide configuration stored in a file, what format / language do you usually choose for this?  and how do you go about doing this in Python?  do you have a favorite module, SDK, or package to help you do this?
I prefer JSON.
(Sep-18-2017, 10:15 AM)wavic Wrote: [ -> ]I prefer JSON.

do you just use the json module that comes in python for all your configuration magic done in JSON?  do you have a typical config file you can share?
I'll take the opposite position: I hate json.  It's better than xml, but that's not a very high bar.  They're both read-only languages.

In my opinion, if a config file is meant to be edited by humans, it should be fairly loose in what it allows, and be pretty obvious on how to structure it.  To that end, I like yaml and toml.  Even .ini files aren't bad.

json just has too many weird quirks which makes it unsuitable for editing by hand, like how it's illegal for the last element in a list to end in a comma. 
# invalid json:
[
    "item1",
    "item2",
    "item3",
]
I believe in making files you save human editable. I generally customize the file format. Each object that is going to be saved has methods to convert it to and from text. For a while at work I was using a data format I created called GeoRGe (.grg, generally readable garbage), that was both computer and human readable, and reasonably humanly editable.
(Sep-28-2017, 07:22 PM)nilamo Wrote: [ -> ]I'll take the opposite position: I hate json.  It's better than xml, but that's not a very high bar.  They're both read-only languages.

In my opinion, if a config file is meant to be edited by humans, it should be fairly loose in what it allows, and be pretty obvious on how to structure it.  To that end, I like yaml and toml.  Even .ini files aren't bad.

json just has too many weird quirks which makes it unsuitable for editing by hand, like how it's illegal for the last element in a list to end in a comma. 
# invalid json:
[
    "item1",
    "item2",
    "item3",
]
i don't hate json, but i do agree with "it should be fairly loose in what it allows, and be pretty obvious on how to structure it."  i have encountered yaml once before and didn't like it.  i have not heard of toml bafore.  i currently use python as my config language.

i think there is a difference how some programs and humans (want to) handle configuration:

1.  the program interacts with the human to get configuration settings and store them in the chosen format.  some programs (their developers) want to have that file be human readable and/or editable in a limited way where it is easy to change single things like a number (3.15159), symbol (Pi), time duration (1h22m30s), or file path ("~/images/big-bg.png")., but not structure.  and some programs (their developer) just give up on human editing and use a binary format.  this decision can easily vary by language, for C/asm and maybe C++ the easy choice is binary, for Pike/Python the obvious choice depends on the tools that are known.

2.  the program expects the user to create a "configuration" or "working data" from scratch either with a text editor or some other program.  one example in this category is bind, the DNS server, which has both the the list of domains and zone files as working data.

i like to use Python source code itself as the config language because it can be simple or complex at the choice of the human who codes it.  the last element in a list can end in a comma, etc.  i use it as category 2 but also have a nice tool to make it work in category 1.

i think XML is intended for category 1 and/or "working data" not created by humans, like a database transfer.

i think JSON falls in the middle.

i've seen some variations on .ini format.

the format bind (the DNS server) uses for configuration looked familiar from my mainframe days (VM/CP/CMS).  but back then i coded almost entirely in Assembler or Rexx.  it would have been nice to have had Python back then.

i use a few tools i created (long before i did Python) to help create DNS zone files for bind.
The main problem for json is that it doesn't support comments at all.  So it's completely unsuitable for config files of any length, as you can't leave notes behind about what the different options are.  Either that, or all your config names are ridiculously long in order to get across the meaning and formatting and usage, like...
{
    "email_receiver_list_for_twice_monthly_billing_report_semicolon_separated": "[email protected];[email protected]"
}
I didn't actually write any program that needed to use a config file. But  JSON is pretty straightforward to keep the configuration for a file - key: value. And is readable enough for me
(Sep-29-2017, 03:06 PM)nilamo Wrote: [ -> ]The main problem for json is that it doesn't support comments at all.  So it's completely unsuitable for config files of any length, as you can't leave notes behind about what the different options are.  Either that, or all your config names are ridiculously long in order to get across the meaning and formatting and usage, like...
{
    "email_receiver_list_for_twice_monthly_billing_report_semicolon_separated": "[email protected];[email protected]"
}
that's one of the reasons i like the python fomat.

(Sep-29-2017, 08:14 PM)wavic Wrote: [ -> ]I didn't actually write any program that needed to use a config file. But  JSON is pretty straightforward to keep the configuration for a file - key: value. And is readable enough for me
so how would you add comments in such a config file?
As another key: value.
{
  [
    {'key':''value',
     'data':'data',
     'comment': 'stupid example'
     }
  ]
}
Pages: 1 2 3