homepage

> Why is the first key built up as vx='x'; vx += '1' instead of just k1="x1"?
I wanted to construct a key that is equal to, but not the same object as, `'x1'`. Consider this example:
 assert 'x1' is 'x1'
 spam = 'x1'
 assert spam is 'x1'
 eggs = 'x'
 eggs += '1'
 assert eggs == 'x1'
 assert eggs is not 'x1'
 assert sys.intern(eggs) is 'x1'
When doing a dict lookup and the lookup key is the same object as a stored entry, `__eq__` is not called. Lookups are then significantly faster, maybe 20%.
Consider this example:
 class EqTest:
 def __eq__(self, other):
 raise RuntimeError
 def __hash__(self):
 return id(self)
 
 adict = {}
 k1 = EqTest()
 k2 = EqTest()
 
 adict[k1] = 42
 adict[k2] = 43
 print(adict[k1], adict[k2])
Here `k1` is considered the same as `k1` and `k2` is considered the same as `k2`. However, `k1` and `k2` are considered distinct and never compared because they have different hashes.
However, if we were to set `EqTest.__hash__ = lambda self: 42`, we'd get a RuntimeError when we try to set `adict[k2]` because it would get compared for equality with `k1`.
Even if `__eq__` works, we can get some interesting behaviors. For example, when using multiple instances of `float('nan')` as keys.
> Using a str subclass in the test is a great idea, and you've created a truly minimal one. It would probably be good to *also* test with a non-string, like 3 or 42.0. I can't imagine this affecting things (unless you missed an eager lookdict demotion somewhere), but it would be good to have that path documented against regression.
I also tested a custom class that compares equal to strings. Other than being much slower, there weren't any significant differences. I also did some checks with int key lookups, which obviously fail with KeyError. They did not make the performance worse for the subsequent str lookups.
I will try to make a proper test tomorrow.