[stdlib-sig] ConfigParser - parsing options with no value

[Michael Foord]

Sorry to top-post, sent from phone-like-device.

Actually Guido has shot down the inclusion of ConfigObj on the past,  
so it doesn't seem worth a PEP.

He doesn't like that sections inherit from dict (although they are  
functionally key-value mappings) as it gives them an over-wide API.  
This is fair enough.

He also fundamentally disliked the idea of nested sections, doesn't  
see the need and suggested people should be using XML for this kind of  
use case! It is an often requested feature, so this I thought was odd.  
Anyway, so be it.

Michael

--
http://www.ironpythoninaction.com

On 18 Sep 2009, at 00:59, Jesse Noller <jnoller at gmail.com> wrote:

>
>
> On Sep 17, 2009, at 7:34 PM, Michael Foord  
> <michael at voidspace.org.uk> wrote:
>
>> Georg Brandl wrote:
>>> Brett Cannon schrieb:
>>>
>>>> On Thu, Sep 17, 2009 at 09:53, Mats Kindahl <mats at sun.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently using the ConfigParser module to parse MySQL  
>>>>> configuration files.
>>>>> Just plain config files, nothing fancy except... options without  
>>>>> values.
>>>>>
>>>>> There is a number of options here that does not require a value,  
>>>>> they are
>>>>> basically just turning on a feature. They are also common in the  
>>>>> standard
>>>>> template files for the server. Options that are for mysqld can  
>>>>> have a value even
>>>>> though it is not required and the option file parser will not  
>>>>> complain, but for
>>>>> some of the client tools, values may not be given or there will  
>>>>> be a error.
>>>>>
>>>>> Looking at the tests of ConfigParser, I see that it is a  
>>>>> deliberate design
>>>>> decision to not allow options without values (or I am  
>>>>> misunderstanding
>>>>> something). Why?
>>>>>
>>>>>
>>>> Who knows. =) Module is old enough it's quite possible no one
>>>> remembers why.
>>>>
>>>
>>> Good point.  There's also an awful shortage of config parsers in  
>>> the standard
>>> library; we should add one or two.
>>>
>>> Georg
>>>
>>>
>> I happen to know a good one we could add. ;-)
>>
>> Michael
>>
>
> +1 I eagerly await a PEP