Is there any reason *not* to cache an object's hash?

I've written a class whose .__hash__() implementation takes a long time to execute. I've been thinking to cache its hash, and store it in a variable like ._hash so the .__hash__() method would simply return ._hash. (Which will be computed either at the end of the .__init__() or the first time .__hash__() is called.)

My reasoning was: "This object is immutable -> Its hash will never change -> I can cache the hash."

But now that got me thinking: You can say the same thing about any hashable object. (With the exception of objects whose hash is their id.)

So is there ever a reason not to cache an object's hash, except for small objects whose hash computation is very fast?

Sure, it's fine to cache the hash value. In fact, Python does so for strings itself. The trade-off is between the speed of the hash calculation and the space it takes to save the hash value. That trade-off is for example why tuples don't cache their hash value, but strings do (see request for enhancement #1462796).

The usual reason is that most objects in Python are mutable, so if the hash depends on the properties, it changes as soon as you change a property. If your class really is an immutable and (all the properties which go into the hash are immutable, too!), then you can cache the hash.

hash(obj) == id(obj) does not hold in general:

    >>> class A(object): pass
    ... 
    >>> a = A()
    >>> hash(a), id(a)
    (8762051845337, 140192829525392)