[Python-Dev] ConfigParser shootout, preliminary entry

[Ian Bicking]

Guido van Rossum wrote:
>>I like the optional type idea:
>>
>>    opt(section_name, key_name, default_value, type)
>>
>>So it can be written this way:
>>
>>    opt('section', 'key', None, StringType)
>>
>>...but -- to answer your question -- the point here isn't really the
>>'singleness' of the factory function, but the fact that it is
>>type-independent, which (in principle) would allow it to be extended
>>to handle arbitrary types by delegating some functionality to the
>>types themselves.
> 
> 
> This is all a nice generalization, but I don't see that much use for
> it. There's only a handful of types that are worth supporting here. So
> the cost of the generalization isn't worth the benefits.

I definitely disagree.  A common case is a constrained type, where only 
a limited number of strings are allowed.  Or an IP address, or domain 
name, or an internationalized boolean converter ("si" -> True), or a 
color specification, or a valid CSS class name, or... well, the list 
goes on forever.

The advantage of putting this in the parser is that you could have 
better error messages when the values were malformed.  If the parser 
doesn't do the conversion, you are likely to have lost the location 
information by the time you try to do the conversion.  Good error 
messages are one of the primary visible features for people who use the 
configuration files.

An additional complication, though; if you plan to make the 
configuration file writable, these types shouldn't just support 
converting from a string to a Python type, but the other direction -- so 
that ambiguous Python types (like a boolean; easily confused as an 
integer) can be converted in specific ways to a configuration string.  I 
don't think __repr__ or __str__ of the value to be converted are 
necessarily appropriate.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org