configobj-develop

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

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

After many months, we are actually starting to use ConfigObj on the job.
Expect many comments and fixes soon. :-)

Let me also introduce my esteemed colleague, Francesco Del Degan.
Francesco, please subscribe to this mailing list, and start firing away. :-)

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

...I do no real world applications like triple mersenne first person
shooters, only business software like the one which in earlier time
was written in COBOL or carved into cave walls. Less challenge,
higher reward. -- Harald Armin Massa, November 2005

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

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

Nicola Larosa wrote:
> After many months, we are actually starting to use ConfigObj on the job.
> Expect many comments and fixes soon. :-)
>
> Let me also introduce my esteemed colleague, Francesco Del Degan.
> Francesco, please subscribe to this mailing list, and start firing away. :-)
Fixes :-o
 
Are you maligning our code ;-)
 
Anyway, that's good news.
 
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
 
I do know of at least two users who use the ``walk`` method, so we 
probably need to keep it. One possibly uses the rename method. Hmmm...

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.

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.

It occurs to me that it would be possible to create a much smaller 
'reader only' which doesn't support validation or writing. That would be 
especially true if some of the dictionary methods were also removed. It 
wouldn't be very much work as it would be almost straight 'ripping-out' 
of code.

Anyway, this all me just 'thinking-aloud'. Feel free to comment or not. :-)

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

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

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

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


> I do know of at least two users who use the ``walk`` method, so we
> probably need to keep it.

I'd keep that one, yes.


> One possibly uses the rename method. Hmmm...

Is it just a shortcut for one reassignment plus one deletion? It doesn't
seem worth much.


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


> It occurs to me that it would be possible to create a much smaller
> 'reader only' which doesn't support validation or writing. That would be
> especially true if some of the dictionary methods were also removed. It
> wouldn't be very much work as it would be almost straight 'ripping-out'
> of code.

Having done the above, maybe a read-only version wouldn't be that much
appealing anymore. Even if it would still be so, I would not manage and
distribute it separately, but maybe have the read-write one subclass, and
add one file to, the read-only one.

But I wonder whether it would be worthy the added complication.

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

...I do no real world applications like triple mersenne first person
shooters, only business software like the one which in earlier time
was written in COBOL or carved into cave walls. Less challenge,
higher reward. -- Harald Armin Massa, November 2005

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