configparser - which one?

[dboland9 at offilive.com]

Thanks Cameron.

Dave,

March 26, 2019 12:39 AM, "Cameron Simpson" <cs at cskk.id.au> wrote:

> On 25Mar2019 23:24, Dave <dboland9 at offilive.com> wrote:
> 
>> On 3/25/19 10:58 PM, DL Neil wrote:
>>> On 26/03/19 1:10 PM, Dave wrote:
>> 
>> I use Python3 3, and expected learning how to use configparser >>>would be no big deal.  Well! 
>> Seems there is configparser, >>>stdconfigparser, and safeconfigparser, and multiple ways to set
>>>>> the section and entries to the section.  A little confusing.  I >>>want to future-proof may
>> code, so what should I be using?
>>> (with apologies for not answering the question directly)
>>> 
>>> After striking this problem, I was encouraged to take a look at >>JSON, and thence YAML. Once
>>> there, as they say, didn't look back!
>>> - multi-dimensional possibilities, cf .ini
>>> - similarity/correspondence with Python data structures
>>> - convenient PSL
>>> - easily adopted by (power-)users, cf Python code
> 
> [...]
>>> 
>> 
>> Wish I could do that. Customer wants .ini. I would need to sell them >on an alternative. The issue
>> is human readable - .ini is easier for >people to understand.
> 
> And I agree with the customer, absent more info. Unless you need deeply nested stuff, .ini is much
> easier for humans to read. Not everything is a match for it (unless you start playing games with
> "[clause.subclause.subsubclause]" stuff, which I'd argue is a smell indicating a format change
> might be good).
> 
> But for stuff which does fit nicely into .ini, it is FAR FAR easier on the reader. Like JSON, YAML
> etc are far far easier than XML for the reader.
> 
> Lots of stuff, particularly simple configs, go well in .ini.
> 
> All that opinion aside: just use the configparser.ConfigParser class. It is what _used_ to be
> "SafeConfigParser" in Python 2.
> 
> Here endith the lesson.
> 
> Cheers,
> Cameron Simpson <cs at cskk.id.au>