At 07:34 AM 8/4/04 -0700, Guido van Rossum wrote:
Probably not, but making Exception a new-style class won't be easy.
What makes you say that? I've just been remarking on comp.lang.python how having Exception be new-style in PyPy -- indeed, not having old-style classes and all -- has caused essentially no problems at all.
I believe that -- it's more that the existing infrastructure that creates the standard exception hierarchy isn't easily adapted.
I also believe there's a conceptual problem with defining when something is an acceptable argument to 'raise' -- unless we insist that exceptions inherit from a designated base class, *every* object is acceptable, because if it isn't a class, it's an instance of a class, and raise allows either. I don't really think that "raise 42" ought to be acceptable, but I don't know how to prevent it without requiring a specific base class (excluding a whole slew of specific base classes seems wrong).
Maybe we can accept old-style classes and instances, strings, and instances of Exception and its subclasses. But then we better be sure that we really want to insist on subclassing from Exception, because that's rather unpythonic.
I thought that was already the plan; I seem to recall dire warnings that it was going to be required someday. In any case, I had my eye on "fixing" this for next bug day (there's a SF bug # for it, that I don't recall at the moment). My plan was to allow any object that was an instance of Exception, even if it was new-style. In other words, new-style exceptions would have to include Exception in their base classes. Old-style exceptions wouldn't have to meet that requirement, for backward compatibility purposes. I assumed that the old-style (and string) compatibility would need to remain until 3.0.