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.
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