[Rest2web-develop] Re: ConfigObj 4 work

[Michael F. <mi...@pc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oops - seems like administrator isn't automatically subscribed...
bizarre. Here's some stuff on ConfigObj 4.

Nicola Larosa wrote:
[snip..]
>
>>>I've added a ``SimpleVal`` object for doing dummy validation (achieves
>>>the same thing as the old 'partial configspec' - just checks members are
>>>present).
>>>
>>>I've added your iter methods into Section - so that it behaves minor an
>>>ordered dicitonary. A couple of slight changes you might want to use in
>>>odict - I use ``repr`` rather than ``str`` in the ``__repr__`` method,
>>>and ``popitem`` is also ordered.
>
>
> Rewrote __repr__, I like it better like this:
>
>     def __repr__(self):
>         items = []
>         for key in self._keys:
>             items.append('%s: %s' % (
>                 repr(key), repr(self[key])))
>         return '{%s}' % ', '.join(items)
>

Yeah that's nicer.

>
>
>>>I've also started on the ``writein`` method - which will be a bit tricky
>>>to get right, but I think I know how I'll do it.
>>>
>>>If you get a chance - can you look at the ``TODO`` and ``ISSUES``
>>>section, and any questions in the source !
>
>
> That's next in line. :-) Let's switch all dev discussion to the
> rest2web-dev ML, I'm subscribed now.
>

Done :-)

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


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

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.

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.

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.

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

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

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

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

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

That will do for the moment.....

>
>
>>>There are a couple of
>>>implementation decisions still to be made. e.g. should I prefix the
>>>private methods with a double underscore ?
>
>
> Single underscore is enough, I'd say.
>

Ok - I'll start that.
I've now added ``__all__`` and ``Section`` is not a public object.


>
>
>>>Once I've written ``writein`` - I'll preserve comments. I think I'll do
>>>this using a comments attribute for each section. I'm going to start by
>>>just preserving inline comments - you can preserve comments *above* a
>>>member by using the ``writein`` method ! Once these two features are
>>>done then it will basically be ready. Just the documentation !
>
>
> Are the docs for ConfigObj3, if any, still applicable, at least partially?
>

Probably large chunks are still applicable, but it *all* needs
rewriting. The ``validate.Validator`` class is poorly documented (and I
*didn't* write the example functions !).


>
>
>>>By the way - sending encrypted mail makes it difficult (not impossible)
>>>for me to receive mail at home (I use the PDA). When I leave on
>>>Saturday, it will make it impossible !
>
>
> Then I'll revert to signing only, not may big secrets to protect anyway. ;-)
>
:-)

Not yet.

Regards,

Fuzzy
http://www.voidspace.org.uk/python


>
> --
> 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzRem59Olk6wiv6IRAlWsAKDEaFrzneIZNfnjJGhViVVh9p+HHACghhof
chIKs5sIghLZ0psmN1lLmDA=
=///K
-----END PGP SIGNATURE-----