> I like ValueError best when an input is of the right type but > outside the defined domain of a function, like math.sqrt(-1.0) or > chr(500). Failing to find something feels more like a (possibly > proper subclass of) LookupError to me. Yeah, [].remove(42) raising ValueError is a bit weird. It was put in before we had the concept of LookupError, and the rationale for using ValueError was that the *value* is not found -- can't use IndexError because the value is chosen from a different set than the index, can't use KeyError because lists don't have a concept of key. In retrospect, it would have been better to define a SearchError, subclassing LookupError. OTOH there's something to say for fewer errors, not more; e.g. sometimes I wish AttributeError and TypeError were unified, because AttributeError usually means that an object isn't of the expected type. --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