Re: [Configobj-develop] Re: ConfigObj Changes

[Nicola L. <ni...@te...>]

>> I am going to implement these as section methods. My initial idea was
>> to implement them using the ConfigParser names and syntax. This means
>> you would have to specify a subsection, but could specify None to get
>> values in the section you are calling from.
>> 
>> In order to avoid this there are three (reasonable) options :
>> 
>> 1) Implement ``asbool`` *and* ``getbool`` methods - ``getbool``
>> following ConfigParser signature.
>> 2) Just implement ``asbool`` and leave ``getbool`` for a ConfigParser
>> compatibility layer - if it ever happens.
>> 3) Implement ``getbool`` but make the second argument optional (by
>> having None as the default). If no second argument is specified, treat
>> the first argument as a key *not* a section...
>>
>> I have a mild preference for 2) but quite like 3). 3) is weird because
>> it changes the meaning of the first argument *if* you provide a second...
>>
>> Opinions please...

> Actually I like 3. It keeps compatibility with ConfigParser (benefit of
> familiarity), and achieves both aims.
> 
> If you supply one argument it's a key, if you supply two they are
> ``section, key``.
> 
> Oh, except it's ``getboolean`` not ``getbool``. :-)

I think I'll disagree here. I concur that having to specify None for no
subsection is a bit inconvenient. However, breaking the rule that optional
parameters should be last in the signature is worse, IMO. I seem to recall
a couple such cases in the standard library, and they feel out of place and
inconsistent with the rest.

Moreover, with option 3) you're not really compatible with ConfigParser
anymore, since you changed the signature, by allowing one to use just one
param. That may cause surprises in case of mistakes.

Maybe it would be better to have separate methods with just one param, and
that would be option 1), if I'm not mistaken.

-- 
Nicola Larosa - http://www.tekNico.net/

People just don't want to be pestered - they want shit to happen
without being bugged. If technology is to help, it must be seren-
dipitous rather than strident. -- Nathan Torkington, November 2005