Re: [Rest2web-develop] Re: ConfigObj 4 work

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

> I'll list the questions I have, answer any you can be bothered with :-)

I'll try. :-)


> 1) Part of the point of ConfigObj is that you can create config files
> from a program. Something like :
> 
> 	config = ConfigObj()
> 	config.filename = 'new.ini'
> 	config['member1'] = value1
> 	config['section1'] = {}
> 	config['section1']['member1'] = value1
> 	...
> 
> 	config.write()

I like this, I need this. :-)


> As it is to be written to a file - the only valid values to set are
> strings, lists of strings, or dictionaries (containing strings or lists
> of strings or...). Should we do type checking when the value is set ?
> (not very difficult). This means the error would be raised when you *set
> the value*, rather than when you try to write the file - which may be
> another part of the program.

Can't see the need for this limitation. The datatype may be any: a number,
a flag, a date. Its *representation* is a string: it will be written to
file, and when read back, the data will be converted back to its type, with
validation.

Anything less than this is insufficient.


> In ConfigObj 3 type checking was optional. There was also a
> ``stringify`` option. If set this automatically converts all values to
> strings when writing. (So you can just assign integers etc without
> having to do conversion yourself !).
> 
> My preference is to do type checking and no longer provide the stringify
> option.

The type checking should be done when reading too: the data must conform,
or be convertible, to the defined type, otherwise the config file is
illegal. (Mmh, this all seems rather obvious; maybe you're talking about
something else entirely?)


> 2) Also in ConfigObj 3 - you could assign a new value to None - and it
> would initialise the value to an empty section. You now do this with an
> empty dictionary (which also worked in ConfigObj 3). I'm opting to lose
> the option of setting a value to None to initialise it.

I agree. "Explicit is better than implicit."

On the other hand, if you opt to lose the option, then you won't have the
option anymore. ;-D


> 3) ConfigObj 3 allowed multiline comments of the \*.....*\ variety.
> Shall I reimplement this ?

No, you shan't. ;-) Let them pound on the hash key. YAGNI rules. Less is
better than more. All that jazz. ;-)


> 4) ConfigObj 3 also preserved the comment at the start and end of a
> file. These would be written out by the ``write`` method.

That's useful, OTOH.


> 5) Should I attempt to preserve the amount of whitespace around the
> divider, the type of quoting used, and the amount of whitespace before
> the comment - and then re-use it in the write method ? I'd rather not....

Absolutely not. Reformat mercilessly. After a while, the user will
capitulate, and conform. ;-)


> 6) ConfigParser and ConfigObj allow some recursion in string
> interpolation - a replaced value can also contain a value to replace.
> This can be useful. In ConfigParser, you get a `Max recursion depth
> exceeded' error if you get stuck in a loop. ConfigObj just ignores it.
> Should it raise the error ? (I think it *should*)

Yes, you should check it. OTOH, I'd rather drop the "feature". :-) But
maybe that's taking YAGNI too far.


> 7) In ConfigObj 3 you could specify the encoding of the file being read
> and it would decode to unicode *before parsing*. I've removed support
> for this and added ``decode`` and ``encode`` methods to convert to and
> from unicode after parsing/before writing. This means you can only use
> ascii compatible encodings in config files.

Hooray, KISS rules too! ;-)


> Adding full unicode support
> is possible - but requires the addition of two extra keywords (encoding
> and backup_encoding). Seeing as UTF8 is a full unicode, ASCII compatible
> encoding - I see no need to change yet.

So leave it as it is. :-)


>> Then I'll revert to signing only, not may big secrets to protect anyway. ;-)

> :-)
> 
> Not yet.

In Italy we say "Hope dies last." Do you have anything like that?

Better yet, I'm not even signing the email, the same as I (don't) do with
all the other mailing lists.

-- 
Nicola Larosa - ni...@te...

Adding things just because you can leads to monstrosities like Common LISP,
PL/I, Algol 68 and Perl 6. Adding features only when they add functionality
(or better yet, by removing restrictions) leads to jewels like Python,
Scheme and Eiffel. -- Mike Meyer, comp.lang.python, April 2005