Optimise LiteralType.__eq__ and __hash__ #20423
Conversation
If I'm doing it right, this should be 2% on a profile I'm looking at
hauntsaninja
force-pushed
the
mypylit
branch
from
0467d28 to
f3f79f6
Compare
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
| if self._hash == -1: | ||
| self._hash = hash((self.value, self.fallback)) | ||
| return self._hash | ||
| return hash(self.value) |
There was a problem hiding this comment.
Is this part actually safe? This will make Literal["foo"] and Literal[b"foo"] have same hash (I don't remember why, but we always store the literal bytes value as a string).
There was a problem hiding this comment.
There's also Literal[0] vs Literal[False], both 0 and False hash to zero IIRC
There was a problem hiding this comment.
It's fine for hashes to collide and doesn't affect correctness. You just don't want too many values to collide because then some of your constant time operations become linear.
There was a problem hiding this comment.
Only correctness requirement is that values that compare equal have the same hash
There was a problem hiding this comment.
OK, I see, could you please then add a comment explaining this pef optimization, otherwise it looks like a "typo". Otherwise this PR LG.
3 participants
If I'm doing it right, this should be 1-2% on a profile I'm looking at