> How odd. I was going to say the reverse; that I *always* want to > distinguish between the two, because TypeError almost invariably is a > programming error of some kind, while AttributeError is nearly always an > error that I'm checking in order to have a fallback. E.g.: > > try: > foo = thingy.foo > except AttributeError: > # default case > else: > foo() > > However, if 'thingy.foo' were to raise any other kind of error, such as a > TypeError, it'd probably mean that thingy had a broken 'foo' descriptor > that I'd want to know about. This sounds like a much more advanced use, typical to a certain style of programming. Others would do this using hasattr() or three-argument getattr(); some will argue that you should have a base class that handles the default case so you don't need to handle that case separately at all (though that may not always be possible, e.g. when dealing with objects created by a 3rd party library). Your example argues for allowing to distringuish between AttributeError and TypeError, but doesn't convince me that they are totally different beasts. --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