I'm doing some HDF writing/reading and need to account for some data type issues which aren't entirely relevant here. The short of it is that I am using a sentinel value to represent None in HDF files, but these sentinels are data type specific (to avoid numpy issues with array data types on replacement/write).
Anyway, I have a dict similar to this:
__sentinels = {
np.float64: np.nan,
np.uint16: np.iinfo(np.int16).min,
np.uint32: np.iinfo(np.int32).min,
...
}
The HDF library sticks a numpy dtype on each dataset. So, I read it in and attempt the lookup... which doesn't work. I can work around it, but I'm curious as to what the intended semantics are here. Take this test case:
>>> np.dtype('uint') == np.uint
True
>>> x = {np.uint: 1}
>>> x[np.uint]
1
>>> x[np.dtype('uint')]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: dtype('uint32')
So, ok, they don't hash equally (is my guess here, I'm not a pythonista really). So I try that:
>>> np.dtype('uint').__hash__()
-2588091675660302491
>>> np.uint.__hash__()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: descriptor '__hash__' of 'numpy.uint32' object needs an argument
ok... so I'm assuming that whatever np.uint.__hash__ needs a self arg. Interestingly, it's also callable (np.uint(1.0) -> 1), while np.dtype('uint') is not.
I'm not terribly interested in tracing the source, I have other ways to do this, but I'm really curious as to what the intended semantics are here.