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

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

> Ok - we have either a confusion or a difficulty ;-)
> 
> Everything is written as a string - surprise, surprise. That means when
> it's read back, it's a string again.
> 
> It sounds to me like you want the validation process to also do type
> conversion ? (So that a value you set as an integer - although written
> and read back in as a string, becomes an integer after validation).

That's correct.


> Currently validation checks whether your read values (strings) conform
> to whatever standard you set. It currently *doesn't* allow the
> validation process to alter the stored values.
> 
> ``validate.test`` returns a single True/False - pass/fail for each test.
> 
> I could also write a transforming test that returns a tuple of : (pass,
> newvalue)
> 
> This would allow the validation process to also transform values for you.
> It means two things :
> 
>     a) You must be allowed to set non string values on a ConfigObj
>     b) You need a stringify option to transform all non-string values
> when writing out

A bidirectional to-from-string typing system. I'm still vague about the
schema that describes types. Maybe we could take a page from Python and let
the types be dynamic, but then how do we recognize the type of a value in a
string read from the config file?


> The sort of type checking I'm talking about is when your program has a
> bug and you accidentally set a value to be ``None`` or to be a class
> instance by mistake. When you come to write out the file - we crash
> because the value isn't a string.
> 
> If we *automatically* stringify non-string values, you won't see the
> problem till much later.

If the schema specifies the type for params, you catch the problem right
away. The stringification should only happen later, when writing to file,
and shouldn't be burdened with type checking concerns.


> If we allow the program to crash in the ``write`` method (as currently)
> - this may actually be called from a totally different part of your
> application that set the value - hard to track.
> 
> If we do type checking when you set the value - the code that sets the
> value is the code that raises the error - easier to trace.

Indeed.


> My view is that a ConfigObj represents the *config file*, and so it
> makes sense to keep values as strings. Validation allows you to check
> that your string does represent an integer, or represent a bool, or
> whatever - but you do the conversion yourself.
> 
> You want (I think ?) the ConfigObj to represent the config data - so you
> want the validate option to change the type of value from strings to
> integers etc.

The config file is just a kind of backend, an implementation detail. It
could be a database connection, a link to cyberspace, or a time-space
machine that reaches back to Pico de la Mirandola. ;-) What I'm interested
in is the config *data*, in fact. The config data should be accurate, and
consistently typed. Such concerns are better handled in the config system,
instead of diluting them in the main program.

This of course complicates the config system. ZConfig, for instance, goes
to great lengths to embed the config schema and types in the config objects
themselves, reaching unheard-of levels of complexity. :-|


> I'm quite happy to add to validate so it can transform values, add
> *optional* type checking, and add a ``stringify`` option that is *on* by
> default. This means ConfigObj will work with either model.
> 
> There will be a new keyword for the validate method - which will cause
> it to *either* use ``val.test`` or ``val.transforming_test``.

So, how do you specify what the value types should be? You have talked
about this before, but it's still not clear to me.


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

> YAGNI ?????

You Ain't Gonna Need It. A popular acronym around Python circles.


> Anyway - cool.. I'll lose multiline comments.

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

> lol - OTOH their nicely lined up config files will become all jagged,
> but unavoidable really.

Why? I was thinking about the opposite outcome instead, a lesson in tidying
up. :-)


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

> Hmm... I can't think of anything directly equivalent. Their maybe
> though. Ha - doesn't sound too hopeful though ;-)

Italians often manage to be catholic and sceptic at the same time. ;-)


> Cool - useful stuff.

:-)


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