Hacker News Reader

Comment by jiggawatts | Hacker News Reader

This seems like a loaded footgun: anyone writing a custome hash function has to know about -1 being treated like an error and handle it in a similar way.

I can’t think of any other language where this kind of thing happens, which means other developers won’t expect it either.

I can see the bug report now: “certain records cause errors, occurs only for about one in a few billion.”

View on HN

If you're writing a custom hash function in python for a custom python class, then this won't affect you since it's only treated as an error in the underlying C code.

If you're adding a new type to the core python language then you have to be aware of this, but if you're hacking the C implementation to change the core language then you're probably pretty well versed in the cpython internals, or at least surrounded by people that are.

interestingly enough though, it doesn't seem to be possible to write a custom hash function that returns -1

   >>> class Foo:
         def __hash__(self):
           return -1

   >>> f = Foo()
   >>> print(hash(f))
   -2

So if you're doing something where you have a custom __hash__ function that you're expecting to return -1 for a certain value and then are testing for value of the hash of an object rather than testing the property of the object directly, then this might bite you. But I cannot think of any reasonable case where you might want to do that.

You can write a custom hash method that returns -1 (and the one you wrote verifiably does.)

The standard (not custom) hash function, in CPython, which calls your custom method and returns the actual value CPython uses for bucketing, will return -2 in that case, though.

Which is necessary, so that, e.g., following the single mathematical function for hashing of numeric types published in the Python Language Reference will preserve x==y implies hash(x)==hash(y) for custom and build in numeric types in CPython where hash(-1) does not follow that pattern.

Even though for -1 itself, the divergence from the rule is in __hash__ itself. This is also consistent with the basic rule that dunder methods are for communication with the standard machinery, but external consumers should use the standard machinery, not the dunder method.

Perhaps the worry was that because the observed behavior up until now was that hash never returns -1, if it were possible possible to write a custom hash function that returns -1, that might break some unsuspecting code due to Hyrum's Law.

If the built-in hash function returned -1 when a custom __hash__ method did so, then custom numeric classes following the hashing guidelines in the Python Language Reference designed to maintain the x==y => hash(x)==hash(y) invariant would fail to maintain that invariant on the reference implementation of Python due to a CPython implementation detail, which would be a Bad Thing™.

I don't think so. This is true for people writing cpython. But if you implement custom `__hash__` method, you should be fine.

Reply on news.ycombinator.com