On Wed, 16 Mar 2022 at 00:42, Cameron Simpson <c...@cskk.id.au> wrote: > > Is it sensible to compute the hash only from the immutable parts? > Bearing in mind that usually you need an equality function as well and > it may have the same stability issues.
[...] > In that case I would be inclined to never raise TypeError at all. I'd > compute the hash entirely from the keys of the dict and compute equality > in the normal fashion: identical keys and then equal corresponding > values. That removes the requirement that values be immutable and/or > hashable. Well, I followed PEP 416, so I allowed immutable types for values, as tuple does. Also tuple is hashable only if all its values are hashable. The equality function is the same as dict, with a little modification. I do not check for hash in equality. I could add that, if both the hash are calculated and different from -1 and they differ, False is returned. > >In this case I currently cache the value -1. The subsequent calls to > >__hash__() will check if the value is -1. If so, a TypeError is > >immediately raised. > > This will also make these values behave badly in dicts/sets, as they all > hash to the same bucket. Not sure to understand. If the hash is -1, it's not hashable, so it can't be a member of a dict or set. > You could, you know, cache the original exception. I thought about it :) What prevented me is that is another PySsize_t to store in memory -- https://mail.python.org/mailman/listinfo/python-list
