Re: [Configobj-develop] Parameterizing list validation

[Michael F. <fuz...@vo...>]

Patches definitely accepted. :-)  (with tests and documentation 
naturally...)

Michael

David Hostetler 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.
>
> regards,
>
> -hoss
>
> David Hostetler
> neg...@gm... <mailto:neg...@gm...>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> ------------------------------------------------------------------------
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog