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@colorstudy.com / http://blog.ianbicking.org