Brett Cannon wrote:
> 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.
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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
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
