Best practice for caching hash
Marco Sulla
Marco.Sulla.Python at gmail.com
Wed Mar 16 09:00:13 EDT 2022
On Wed, 16 Mar 2022 at 00:42, Cameron Simpson <cs at 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
More information about the Python-list
mailing list