I was messing around with a small custom data object that needs to be hashable, comparable, and fast, when I ran into an odd-looking set of timing results. Some of the compa
Two reasons:
The API lookups look at the type only. They don't look at self.foo.__hash__
, they look for type(self.foo).__hash__
. That's one less dictionary to look in.
The C slot lookup is faster than the pure-Python attribute lookup (which will use __getattribute__
); instead looking up the method objects (including the descriptor binding) is done entirely in C, bypassing __getattribute__
.
So you'd have to cache the type(self._foo).__hash__
lookup locally, and even then the call would not be as fast as from C code. Just stick to the standard library functions if speed is at a premium.
Another reason to avoid calling the magic methods directly is that the comparison operators do more than just call one magic method; the methods have reflected versions too; for x < y
, if x.__lt__
isn't defined or x.__lt__(y)
returns the NotImplemented
singleton, y.__gt__(x)
is consulted as well.