Re: [Configobj-develop] Re: ConfigObj Changes

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

>> 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.

> I can see your point.
> 
> *However* there is a current discussion of ConfigObj going on in
> python-dev. Ian Bicking mentions about having *too much* in the API.
> Implementing two means of doing similar things seems like overkill.

That's also true, I agree that the API should be as frugal as possible.


> Do you greatly prefer ``getboolean`` (allowing but requiring you to
> specify a sub-section) to ``asboolean`` (not requiring or allowing you
> to specify a sub-section) ?

No, I don't. It only seems useful for ConfigParser compatibility,
subsect.as_bool(key) (I'd like it shorter and clearer) is simpler and
functional.


> Just implementing ``asboolean`` leaves the way open for ``getboolean``
> in a subclass (implementation of either is trivial).

Then option 2) it is.

-- 
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