Re: [Configobj-develop] Finally getting to use ConfigObj :-)

[Michael F. <fuz...@vo...>]

Nicola Larosa wrote:
>> I'd like to minimise any future API growth as much as possible.
>>
>> I'd like to *consider* removing the following methods :
>>
>>   encode
>>   decode
>>   rename
>>     
>
>
> Negative API growth is good. :-)
> [snip..]

encode, decode and rename will be deprecated in the next release.

>
>   
>> After Guido's comments I'd even consider *not* subclassing dict, and
>> only implementing those mapping protocol methods that are actually
>> appropriate. Ripping stuff out isn't my *immediate* priority though.
>>     
>
> We have yet to check whether being a dict subclass helps, or not, with
> Twisted's Perspective Broker serialization. I'll let you know.
>
>
>   
I thought you already knew that it didn't ?

>> I've also wondered if there might be any use for a 'ConfigObj-lite' ?
>> ConfigObj now weighs in at around 115k, which is quite hefty if all you
>> want to do is *read* config files.
>>     
>
> More than half of it are doctests, and even more than that for validate.py.
> I'd rather *increase* the size of the archive by including the 2.4 version
> of doctest.py from the stdlib. That way we could separate the doctests in
> their own files, and still have them work on Python 2.2 and 2.3.
>
> That would bring down the file sizes even for the full-feature version.
>
>
>   
+1 if you backport doctest for 2.2 compatibility. :-)

There's a lot of CHANGELOG accumulating *in* the source as well. We 
don't want such a detailed changelog in the docs, so we could either 
move it to a separate file or not worry about it.

If the doctest backport is a possibility, I won't worry about 
configobj-lite until some actually requests it (with a convincing 
use-case). Subclassing is more complicated than you suggest, because 
some of the 'removable' features are in ``Section``. Not a priority in 
any case.

All the best,

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