Hacker News Reader

Comment by Etheryte | Hacker News Reader

I think this is not constructive criticism. There's a good, clear cut reason for this specific overlap (error handling), saying it collides just because is not really useful.

View on HN

But even that’s an implementation detail that happens to be true today, but could easily disappear tomorrow. There’s nothing in the docs saying it has to be that way, or that you can infer anything from a hash output other than that it’s going to be consistent within a single execution of that Python program.

This article is not about the API contract of the hash function, or the abstraction it provides. If you are just trying to hash things, you don't need any info here.

It's very much trying to go _under_ the abstraction layer to investigate its behavior. Because it's interesting.

This is very similar to how people investigate performance quirks or security issues.

I read the article and it's interesting! I learned something from it. From an end user POV it explains the mechanism behind how hash(-1)==hash(-2), which is neat. There's not really a why behind it, though. It wasn't really planned or designed for -1 to have an unexpected hash value. That's just the value the devs randomly picked as a flag. It could've been -837 just as easily.

It could have been a bug. There's nothing wrong with the question and seeking answers to it. It was an interesting read too.

If the article title had been "why does the hash function never return -1", you would agree it's not a random behavior and serves a very clear purpose. It just so happens that the original author didn't know that until they did all the digging (nice job by the way).

Reply on news.ycombinator.com