configparser - which one?
dboland9 at offilive.com
dboland9 at offilive.com
Tue Mar 26 07:26:16 EDT 2019
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>
More information about the Python-list
mailing list