On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > New Hierarchy > > ============= > > > > Raisable (new; rename BaseException?) > > +-- CriticalException (new) > > +-- KeyboardInterrupt > > +-- MemoryError > > +-- SystemExit > > +-- SystemError (subclass SystemExit?) > > I'd recommend not subclassing SystemExit--there are too many programs > out there which expect the argument (e.g. sys.exit(3)) to mean something > specific, but that expectation doesn't apply at all to SystemError. >
Don't forget this is Python 3.0; if it makes more sense we can break code. > > +-- Exception (replaces StandardError) > >... > > +-- ControlFlowException (new) > > I'd definitely appreciate ControlFlowException--there are a number of > exceptions in CherryPy which should subclass from that. Um, CherryPy > 3.0, that is. ;) > =) Well, assuming Guido thinks this is enough of a possible use case. > > +-- LookupError (better name?) > > SubscriptError, perhaps? But LookupError could become the "I didn't find > obj X in the container you specified" superclass, in which case > LookupError is perfect. > That's what it's meant for and renaming it GetitemError doesn't exactly clarify it for newbies. =) I doubt something better is going to be found. > > +-- TypeError > > +-- AttributeError (subclassing new) > > "Since most attribute access errors can be attributed to an object not > being the type that one expects, it makes sense for AttributeError to > be considered a type error." > > Very hmmm. I would have thought it would be a LookupError instead, only > because I favor the duck-typing parts of Python. Making AttributeError > subclass from TypeError leans toward stronger typing models a bit too > much, IMO. > This idea has been brought up before on several separate occasions and this subclassing was what was suggested. It seems a decision needs to be made as to whether the lack of an attribute is a failure of using the wrong type of object, just a failure to find something in an object, or a failure to find a name in a namespace. I lean towards the first one, you like the second, and Guido seems to like the third. $20 says Guido's opinion in the end will matter more than ours. =) > > +-- WeakReferenceError (rename for ReferenceError) > > This also has a LookupError feel to it. > Nope, as Fred explains in his own email. > > It has been argued that Raisable is a bad name to use since it is not > > an actual word [python-dev1]_. > > Perhaps, but compare http://www.onelook.com/?w=raisable to > http://www.onelook.com/?w=raiseable. The only sources "raiseable" has > going for it are Dictionary.com (which aggregates lots of questionable > sources), Rhymezone, and LookWAYup. I think "raisable" is the clear > winner. > And Guido seems fine with it, so unless someone can convince Guido otherwise the PEP will go with Raisable. -Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
