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

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

> I don't think we need to specify the type of the value stored - it ought
> to be unambiguous in the light of the *purpose* of the value. i.e. a
> 'port number' is always going to be an integer, a 'user name' is always
> a string etc. This means that all the validation schema needs to do is
> check that the stored value *makes sense* (can be sensibly converted to
> the required type).

In other words, "duck typing". Very Pythonic. :-)


> I think this is the stage to explain the 'schema' system - using
> ``validate.py``. You can decide whether this meets your needs - or can
> be made to meet your needs.
> 
> The configspec is a file (list of lines, dictionary, whatever) that is
> very like the config file. For each member of the config file, you
> specify (effectively) a function to do the testing.
> 
> e.g. (from the tests)
> 
>         test1='range(30,50)'
>         test2='lower()'
>         test3='integer'
>         test4='alphanumeric'
> 
> The function can be specified with or without parameters. If there are
> no parameters then the '()' is optional. ``val.test`` then maps the
> value in the configspec to a real function call. The function specified
> is passed the value (as a string *or* a list of strings when read from
> the config file) - *plus* any parameters specified in the config spec.
> 
> This means that, from the example above, the member 'test1' must be an
> integer value between 30 and 50.
> 
> ``lower`` checks the value is lowercase, ``integer`` just checks that
> the value is an integer etc.
> 
> So I *don't* think we need to store any type information in the config
> file. Once you have written a general purpose set of functions that
> check the values make sense - all you need to do is write the
> configspec. The validate method then checks each value individually.
> 
> One way of doing it would be to have the functions return the converted
> value *or* raise an exception. They would look something like this :
> 
> def range(value, min, max):
>     if isinstance(value, list):
>         raise Exception
>     if not value.isdigit():
>         raise Exception
>     value = int(value)
>     if not min <= value <= max:
>         raise Exception
>     return value
> 
> If the member is missing, or the test raises an Exception, then it's a
> fail. Otherwise the original value is replaced with the returned new value.
> 
> So we don't need to specify any type info in the config file - the type
> should be obvious from context.

Nobody said that. ;-) I do implied that we could have a some kind of schema
file, where the types would be specified. That's what I know, because
that's what's ZConfig has. Your configspec file looks even better, though,
since it contains constraints on the possible values.


> How does this sound ?
> We can work together on a general set of functions that will cover most
> of your needs (the syntax already allows for your configspec to pass
> keyword arguments or specify multiple tests for a value).
> 
> A lot of are written already - but I think they could be clearer.


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

> Hmm.. I only envisaged using the schema (configspec) to check a file
> once you have read it, although there's no reason you couldn't set the
> values and then validate.
> 
> The schema isn't involved when you *set* individual values. You would
> have to validate specifically afterwards.... (allowing validation of
> individual values at the point when they are set would be messy - I was
> only suggesting type checking in the context of all values being strings
> for writing to a file).

OTOH, checking only when saving means disconnecting the check point from
the set point. Unfortunately, checking at set point means keeping
constraints in the same object holding the data, a firm step towards
ZConfig-level complexity. :-) So yes, I think it's wise dropping such a
requirement.


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

And this is what we just dropped. :-(


> The nice thing about using ``validate.py`` is that you can use the same
> system to check values wherever they come from.

Or wherever they go to. :-)


> Mark Andrews - who I
> designed this with, wanted to use it to validate the same values stored
> in a database and a file.


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

> Well, because if you add white space to your values to line up the
> comments etc.... then the write method will simply add a standard amount
> of whitespace after the value and before the comment.
> 
> It will also write a standard amount of whitespace between value and
> divider, rather than padding it so that they line up.

I reckon there's a specific mention in GvR guidelines to not depend on such
aligning. Not that I hope that many users of ConfigObj will have read them. ;-)

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