At 03:03 PM 6/9/03 -0400, Guido van Rossum wrote:
I guess I'm missing why this wouldn't work for new-style exceptions, provided they are required to subclass Exception (which I thought everything was going to be required to do eventually).
I'm dithering on that, actually. It's a Java vs. C++ thing: in C++ you can raise any type, in Java it must be an Exception instance.
Python usually doesn't care about isinstance relationships but cares about whether the needed protocol is implemented, and this suggests that requiring exceptions to subclass Exception is unPythonic.
Hm. I suppose if we had PEP 246 in the core, we could always 'adapt(ob,Exception)' instead, and also define an adaptation for tuples to become exceptions. ;)
But at other times, the desire to catch bogus arguments to raise suggests that the subclass requirement might be just fine, and I don't have a use case that breaks with this requirement (since you can always use multiple inheritance to make a desirable class raisable).
And I expect that even Jim Fulton won't argue that a subclass of an Exception subclass should be able to change its stripes and *not* be usable as an Exception any more. In other words, I don't think it's any more of a wart than requiring someone to subclass datetime.tzinfo.