BUG: dtype comparison coerces generously leading to problems hashes
See original GitHub issueFor some reason, dtype
objects and the numpy types they are based off of compare equal. They don’t hash equal of course, which goes against Python’s docs that say
The only required property is that objects which compare equal have the same hash value…
Can we make them compare unequal? Is there any reason for them to compare equal?
In [6]: np.dtype(np.float) == np.float
Out[6]: True
Issue Analytics
- State:
- Created 8 years ago
- Comments:18 (18 by maintainers)
Top Results From Across the Web
BUG: Weird behavior for comparison operations `eq` and `ne ...
Looks like the problem is related to size of operands for comparison operations. Could anyone explain please? Is it normal behavior?
Read more >Why do these dtypes compare equal but hash different?
My workaround for this problem is to call np.dtype on everything, after which hash values and comparisons are consistent. python · numpy.
Read more >pybind11 Documentation - Read the Docs
pybind11 is a lightweight header-only library that exposes C++ types in Python and vice versa, mainly to create Python.
Read more >Nmap Change Log
The bug was reported by Daniel Miller. [Zenmap]It is now possible to compare scans having the same name or command line parameters. [Jah,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes, I think so? I imagine I was contemplating this as something to consider for an eventual API cleanup.
@shoyer did you reopen this intentionally?