Re: [Configobj-develop] List handling in Validator

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

I had posted some thoughts awhile back regarding generalization of the list
API.  It doesn't necessarily directly address all of the things that Stefan
is saying, but I think it factors into the discussion:

On Fri, Jul 17, 2009 at 12:41, David Hostetler <neg...@gm...>
 wrote:

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



I do still have that on my queue of stuff to do.  Eventually.  :)

regards,

-hoss


David Hostetler
neg...@gm...