Re: [Configobj-develop] Re: ConfigObj Changes

[Fuzzyman <fuz...@vo...>]

Nicola Larosa wrote:
>>> 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.
>
>   
Done. :-)

I'll set about implementing :

    as_bool
    as_int
    as_float

I'm part way through adding unicode support. Things like checking the
compiled (ascii) regular expressions handle unicode fine and fuller BOM
support make this not-quite-trivial-but-not-too-bad.

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/index.shtml