[Python-Dev] Inconsistent exception for read-only properties?
Guido van Rossum
gvanrossum at gmail.com
Sun Apr 17 20:36:21 CEST 2005
> In 2.4 & 2.3 does it make sense to raise an exception that multiply inherits
> from both TypeError and AttributeError? If anyone currently does catch the
> error raising only AttributeError will break their code. 2.5 should just
> raise an AttributeError, of course.
I think that sets a bad precedent. I understand you want to do this
for backwards compatibility, but it's a real ugly thing in the
exception inheritance tree and once it's in it's hard to get rid of.
It's also introducing a new feature so it's a no-no to do this for 2.3
or 2.4 anyway.
I wonder if long-term, AttributeError shouldn't inherit from
TypeError? AttributeError really feels to me like a particular case of
the stuff that typically raises TypeError. Unfortunately this is
*also* a b/w compatibility problem, since people currently might have
code like this:
except TypeError: ...
except AttributeError: ...
and the AttributeError branch would become unreachable.
Personally, I think it would be fine to just change the TypeError to
AttributeError. I expect that very few people would be hurt by that
change (they'd be building *way* too much specific arcane knowledge
into their program if they had code for which it mattered).
So why, given two different backwards incompatible choices, do I
prefer changing the exception raised in this specific case over making
AttributeError inherit from TypeError? Because the latter change has a
much larger scope; it can affect much more code (including code that
doesn't have anything to do with the problem we're trying to solve).
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev