[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:

  try: ...
  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 mailing list