[Python-Dev] ConfigParser shootout, preliminary entry

[Guido van Rossum]

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

Sure, I agree with all of that. But my original (optint, optstr,
optbool, optfloat) proposal can easily be extended the same way; in
fact it is in some sense easier than an API that expects a type
object. (Unless you have an adaptation framework in place; until we
have a general one, inventing one just for this purpose definitely
feels like overkill.)

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

Actually, repr() or str() probably *is* the right answer for this,
even if calling the constructor with a string argument isn't the
answer for parsing and validation.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)