[Configobj-develop] Parameterizing list validation

[David H. <neg...@gm...>]

[this discussion arises out of the recent post inquiring how to handle empty
values in a list]

I think in general the list validation features might benefit from being
either parameterized or more comprehensive.

By that I mean, for example, that 'force_list' isn't so much a different
validation function as it is a behavior that the author may or may not wish
to apply to any particular list.

In fact, in hindsight I wonder whether instead of having the set of list
functions (list, int_list, float_list, bool_list, etc..) there is simply and
only 'list'.   In addition to the 'min' and 'max' parameters that the list
function accepts, you could add to that things like:

- 'valtype'   (to allow 'valtype=int', 'valtype=float', etc..)

- 'force'  (replacing the 'force_list' function and allowing any kind of
list to adopt the implicit-trailing-comma behavior)

- 'allowgaps'  (to accommodate the missing value behavior Cameron inquired
about)


Thus list() accrues parameters as needed to customize how it validates the
values in a particular instance.

The nice thing here is that the backwards compatibility story is clean:
usage of, say, int_list() is functionally equivalent to list(type=int).
force_list() becomes list(force=True).

mixed_list is still a bit of a black sheep.  But that may be fine anyway.
Technically, all of the other list variants are implicitly for lists of
arbitrary length.  mixed_list is only valid for lists of known length
(otherwise how can you specify the type for each item in the mixed list?).
mixed_list, by its very nature, cannot do implicit type conversions.

In other words -- the set of available validation functions essentially
remains defined as "what kind of thing you get back from the validation".

'integer' gives you an integer
'tuple' gives you a tuple
'list' gives you a homogeneous list of 0 or more items
'option' gives you one string from among a known list of strings
'mixed_list' gives you a (potentially) heterogeneous list of 0 or more items
etc..


There might still be opportunity to refine the relationship between list and
mixed_list, but the trade-off is the complexity of the list() API.

In fact this whole discussion is about the complexity vs. capability of list
validation.  Having force_list() be a top-level validation function grows
the set of functions by one, but keeps the average function complexity low.
But it reduces the capability of the functions because the 'force' behavior
cannot be applied to lists obtained via the other functions -- it's an
either/or choice for the programmer: you can use int_list to get a list of
ints, or you can have force_list to get a forced list of strings, but you
can't have a forced list of ints.

Pushing some of the choices back into parameters increases both the
complexity and the capability of the validation functions, while
simultaneously reducing the number of validation functions (assuming the
redundant functions were then removed or deprecated).


Incidentally -- I would argue that the tuple() validation function has
precisely the same needs for parameterization as does list().  The
parameterization needs arise from the existence of more than one value per
keyword, and that's the case for both lists and tuples.  The only difference
between the two returned types is that one is mutable the other is not --
they're both sequences.  For that matter, why can I get a mixed list but not
a mixed tuple?


Just some food for thought.

regards,

-hoss

David Hostetler
neg...@gm...