configparser - which one?

[DL Neil]

On 27/03/19 2:44 AM, Grant Edwards wrote:
> On 2019-03-26, Cameron Simpson <cs at cskk.id.au> wrote:
> 
>> Like JSON, YAML etc are far far easier than XML for the reader.
> 
> If "far far easier than XML for the reader" is the bar, then we'll
> have to keep "nailgun to the eyeballs" on the list...
> 
> That said, I agree with the rest of Cameron's post: for simpler stuff
> .ini is darn hard to beat.  If you need nesting/arrays, then I'd
> probably pick YAML over JSON.  Making simple changes to an
> automatically-generated JSON file by hand is easy enough. But, I find
> generating anything remotely complex by hand is far easier in YAML
> than it is in JSON.  As usual, YMMV.


In my users' case, choosing YAML was a decision made before the 
(relatively) recent improvements to the .ini interface. (Thanks for that 
news!)

 From a programmer's PoV, the convenience of having whatever 
config-file-rules handled within a library, so that your incoming data 
is 'reduced' to a dict/list structure, cannot be understated.

 From a user's PoV, (the few who should ever be allowed to come into 
contact with such things) both .ini and YAML (and presumably) JSON are 
readily understandable, in my experience (YMMV) - perhaps in this case 
I've been 'blessed' with scientific/math/stats-types who are relatively 
'power users' and used to planning their experiments/analyses!

As far as specs go, I can't say I've ever bothered to read those for 
JSON, YAML, or even .ini. Have you? Read some article(s), started 
'playing', achieved what was required, no fuss-no muss... The previous 
post criticising same, lacks specifics, so can't learn from it. Earlier, 
mention was made of multiple 'dimensions' which are (at least to me, and 
those users) 'cleaner' in YAML/JSON/XML - however, heading 'too far' in 
that direction invites 'trouble'. What does the Zen of Python say about 
simplicity!

As with all tools, one really important criteria is the quality of 
information-provided when things 'go wrong'. We've all been frustrated 
because a 'missing comma/bracket/colon/...' "on line nnn" is not 
supposed to be there at all - and we've had to comb 'backwards' through 
the code to find where the missing punctuation should have been...

Given the relative ease with which both .ini and YAML can (now) be 
utilised (both by 'them' and by 'us'), there are not sufficient 
advantages/disadvantages to make it a 'big deal'. Other factors come 
into play and assume greater import: the OP mentioned 
user-preference/spec; whichever format this user's other systems 
utilise; the ease (reduced cost) of reaching into one's 'bag of tricks' 
for an already-coded ("re-usable") config-function...

-- 
Regards =dn