[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Nick Coghlan]

Brett Cannon wrote:
> On 7/29/05, Robert Brewer <fumanchu at amor.org> 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.

True, but we should still have a decent reason to break stuff. One other thing 
to keep in mind is that it is easy to handle multiple exception classes with a 
single except clause - what is hard to fix in user code is inappropriate 
inheritance between exceptions (cases where you want to 'catch most instances 
of this class, but not instances of this particular subclass').

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

Or if he can be persuaded that ControlFlowException should exist as a peer of 
Exception and CriticalException. . .

>>>    +-- 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.  =)

I think this is a context thing - whether or not an AttributeError is a 
TypeError or LookupError depends on the situation.

In ducktyping, attributes are used to determine if the object is of the 
correct type. In this case, an AttributeError indicates a TypeError.

However, it isn't that uncommon to use an instance's namespace like a 
dictionary to avoid typing lots of square brackets and quotes (e.g. many 
configuration handling modules work this way). In this case, an AttributeError 
indicates a LookupError.

I think it's similar to the common need to convert from KeyError to 
AttributeError in __getattr__ methods - the extra attributes are looked up in 
some other container, and the resultant KeyError needs to be converted to an 
AttributeError by the __getattr__ method. That common use case still doesn't 
mean KeyError should subclass AttributeError.

On the other hand, an AttributeError is _always_ a failure to find a name in a 
namespace (an instance namespace, rather than locals or globals), so having it 
inherit from NameError is a reasonable idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com