configparser - which one?

Dave dboland9 at offilive.com
Tue Mar 26 07:18:29 EDT 2019


On 3/26/19 4:29 AM, Terry Reedy wrote:
> On 3/25/2019 8: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 
> 
> configparser is what IDLE uses.  I would read the extra or deleted 
> features of the others and see if they apply to your client's project.
> 
>> 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?
>>
>> As for setting the sections and entries, the following both work.
>>
>> from configparser import ConfigParser    # Python 3 syntax
>> parser = ConfigParser()
>>
>> parser['DEFAULT'] = {'Language': 'English',
>>                       'Units': 'English',
>>                       'UseDefaults': 'True',
>>                       'NumberRidesDisplay': '30',
>>                       'Pi': '3.14'}
> 
> The dict interface is newer but I doubt that the older one will go away. 
>   (IDLE uses it because it predates the dict interface.  Since this code 
> is pretty static, I do not currently see a payoff for conversion.)
> 
>> parser.add_section('Default')
>> parser.set('default', 'language', 'english')
>> parser.set('default', 'units_measure', 'english')
>> parser.set('default', 'background_color', 'white')
>> parser.set('default', 'useDefaults', 'true')
>> parser.set('default', 'numToDisp', '12')
>> parser.set('default', 'pi', '3.14')
>>
>> The advantage of the former is that it will handle 'DEFAULT', while 
>> the last one won't.  I like the former, but not sure if it is the future.
> 
> We do not remove things and break backwards compatibility lightly.
> 
Thanks everyone.  So, I'll use configparser, but I do like the 
dictionary API as it makes the code a little easier as I can pass as 
arguments a section name and a dictionary with the contents to a 
function to write the complete section.

Dave,



More information about the Python-list mailing list