[Python-3000] PEP 3119 - Introducing Abstract Base Classes

[Adam Olsen]

On 4/27/07, Thomas Lotze <thomas at thomas-lotze.de> wrote:
> Guido van Rossum wrote:
>
> >     Another constraint is that hashable objects, once created, should
> >     never change their value (as compared by ``==``) or their hash value.
> >     If a class cannot guarantee this, it should not derive from
> >     ``Hashable``; if it cannot guarantee this for certain instances only,
> >     ``__hash__`` for those instances should raise a ``TypeError``
> >     exception.
>
> Shouldn't this rather be a ValueError since it occurs not because of the
> type of the object in question, but its value (while in general, there are
> instances of the same type representing other values which are hashable)?

>>> hash([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list objects are unhashable

Normally the exception is raised because the type is wrong.  Requiring
both TypeError and ValueError be caught just for this special case
would be confusing.  A subclass of both could be created, but that
seems pedantic with no practical value.

-- 
Adam Olsen, aka Rhamphoryncus