Michael Chermside wrote:

Guido writes:

...

I find "AttributeError: __exit__" just as informative.

Eric Nieuwland responds:

...

I see. Then why don't we unify *Error into Error? Just read the message and know what it means. And we could then drop the burden of exception classes and only use the message. A sense of deja-vu comes over me somehow ;-)

The answer (and there _IS_ an answer) is that using different exception types allows the user some flexibility in CATCHING the exceptions. The discussion you have been following obscures that point somewhat because there's little meaningful difference between TypeError and AttributeError (at least in well-written code that doesn't have unnecessary typechecks in it).

Yep. I too would like to have 'SOME flexibility in catching the exceptions' meaning I'd like to be able to catch TypeErrors and AttributeErrors while not catching what I call ProtocolErrors. The simple reason is that in most of my apps TypeErrors and AttributeErrors will depend on the runtime situation, while ProtocolErrors will mostly be static. So I'll debug for ProtocolErrors and I'll handle runtime stuff.

If there were a significant difference between TypeError and AttributeError then Nick and Guido would have immediately chosen the appropriate error type based on functionality rather than style, and there wouldn't have been any need for discussion.

I got that already. To me it means one of them may be a candidate for removal/redefinition.

Oh yeah, and you can also put extra info into an exception object besides just the error message. (We don't do that as often as we should... it's a powerful technique.)

Perhaps that needs for propaganda then. I won't dare to suggest syntactic sugar ;-) --eric