> >>...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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4