Re: [Rest2web-develop] Misc fixes, and a last request

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

> My friend has said he will setup the unixshell account for us - but no
> details yet.

Great.


> This is exactly the *opposite* of the way configspecs currently work. If
> no default is specified the value must be specified.
>
> My normal use case is that defaults are not specified and values are not
> optional.
>
> I don't like the 'default is keys are optional' solution - it seems to me
> to reverse the primary rationale of configspecs. Also - it makes writing
> quick and simple configspecs more painful.

I agree. I was just trying to avoid adding another keyword, but didn't like
the inversion of policy either, so keys stay mandatory.

Thinking about it, the specification "default = None" should mean exactly
what it says, that is, if no value is specified in the config, the key gets
the value "None".


> *Also* - None is a possible value to pass to default.

This is the key of the solution to the problem.

Currently, "None" is only usable if a key is of type "none". But such a
type is useless: what can you do with an option that can only assume the
"None" (non-)value? :-) The only use case I currently see is as a value in
"multiple" types.

Thinking more about it, I'd say instead that the "None" type should be a
legal value for all types, with the same meaning as NULL in SQL, that is,
no real value specified. Same meaning as in Python, incidentally. ;-)

Then you can add "default = None" to *any* type, meaning that if no value
is  present in the config, that key gets the "None" (non-)value, that is,
no real value.

This also solves a remaining problem: specifying a default value for list
types, currently not possible.

Obviously, now that "None" is always a legal (non-)value, the "none" type
is not needed anymore, and goes away. :-)


> Possible alternatives :

[mumbo-jumbo deleted ;-) ]

We can forget about all that. :-)


>> A similar issue is the requiredness of sections: I need to be able to
>> omit entire sections from the config, and this is currently not
>> possible.

> An __optional__ scalar value in the configspec ? (true or false)
>
> You could even combine with __optional_scalars__ - and just make
> __optional__ a list that can include sections and scalars. Then only one
> more magic value is needed.

I decided to do away with that, and require that all sections must always
be present, even if empty. It's not worth the added complication.


>> A related issue would be specifying the min and max number of
>> subsections in __many__ sections.

> __min__ and __max__ magic scalars in __many__ sections ?

Archived under YAGNI.


I'm working on this now, today's holiday in Italy, but not in England
apparently, so if you are at work let me know about it as soon as you can.


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

Does it seem like I'm looking for an answer
To a question I can't ask
 -- Norah Jones, Nightingale, Come Away with Me, 2001