Nick Coghlan wrote:

+-- Exception (formerly StandardError) +-- AttributeError +-- NameError +-- UnboundLocalError +-- RuntimeError +-- NotImplementedError

Time to wade in ... I've actually been wondering if NotImplementedError should actually be a subclass of AttributeError. Everywhere I can think of where I would want to catch NotImplementedError, I would also want to catch AttributeError. My main question is whether I would want the reverse to also be true - anywhere I want to catch AttributeError, I would want to catch NotImplementedError. Perhaps instead it should be the other way around - AttributeError inherits from NotImplementedError. This does make some kind of sense - the attribute hasn't been implemented. Both seem to have some advantages, but neither really feels right to me. Thoughts? Anyway, I came to this via another thing - NotImplementedError doesn't play very well with super(). In many ways it's worse to call super().method() that raises NotImplementedError than super().method() where the attribute doesn't exist. In both cases, the class calling super() needs to know whether or not it's at the end of the MRO for that method - possible to find out in most cases that would raise AttributeError, but impossible for a method that raises NotImplementedError. The only way I can think of to deal with this is to do a try: except (AttributeError, NotImplementedError) around every super() attribute call. This seems bad. Tim Delaney