> Which case are you considering? In case 1, __hash__ of the parent object
> is not idempotent because it depends on whether __hash__ of the child
> object has a cached value or not.
I don't see why you should say that; it's certainly not my intent. What did
I say that makes you think that that d
Earlier in the thread:
> two troublesome cases:
[...]
> 1) An object x with a component y that might be hashable. x is hashable
> apart from x.y, but hashing x for the first time has side effects, so the
> value is cached. The hash of x depends partly on the hash of x.y.
[...]
>
> In both cases, __hash__ is not idempotent, and is thus an abomination.
Why do you say it's not idempotent? The first time you call it, either it
works or it doesn't. If it doesn't work, then you shouldn't have called it
in the first place. If it does work, all subsequent calls will return the
I wrote:
> [1] I subtlely switched language from "side effect free" to "idempotent"
> here because caching *IS* acceptable in __hash__ mehtods. If you're
> not paying close attention I probably got away with it.
Andrew Koenig responds:
> I picked it up before seeing the footnote :-)
Yea
> A __hash__ method with side effects is not formally prohibited in the
> documentation but nevertheless, a __hash__ which is not idempotent is
> an abomination.[1] Thus, there is no need for a test of whether __hash__
> will succeed: just try it.
> [1] I subtlely switched language from "side effe
Andrew Koenig writes:
> This issue started out as a question of side effects; from an architectural
> viewpoint, I consider performance to be less important because side effects
> are likely to affect correctness.
Indeed... side effects are the primary concern.
A __hash__ method with side effects
