Repository navigation
BUG: standard dtypes are not singletons #6295
Description
I encountered the following while working on scipy#5213:
In [1]: np.int64 is np.typeDict['longlong']
Out[1]: False
In [2]: set((np.int64, np.typeDict['longlong']))
Out[2]: {numpy.int64, numpy.int64}
In [3]: np.__version__
Out[3]: '1.11.0.dev0+60df9b1'This has implications for things like using dtypes as keys in a dictionary, which is fairly common in the scipy unit tests.
Activity
argriffing commentedon Sep 9, 2015
Is this a duplicate of #5801?
njsmith commentedon Sep 9, 2015
To be clear, dtypes aren't intended to be singletons, and in general this
is fine for dictionaries and sets -- those require objects to be ==, not
'is'.
.
The weird behavior here is a more specific bug related to int64 and
longlong specifically, as @argriffing notes...
On Sep 9, 2015 1:42 PM, "argriffing" [email protected] wrote:
argriffing commentedon Sep 9, 2015
Just for reference, here's a longer comparison. I don't really understand how this works, and I'm not sure which parts of this (if any) are considered buggy. Also, I don't understand exactly how it is related to the issue I linked above. According to @jaimefrio in that thread,
the issue seems to be that PyLong objects are always converted to NPY_LONGLONG, even when it is the same size as NPY_LONGbut I'm not sure if this is the same issue causing confusion here, or even if that issue is the one that @njsmith had in mind when referring toa more specific bug related to int64 and longlong specifically.jorenham commentedon Jul 22, 2026
Your conclusion about
int64andlonglong(which are scalar types, not dtypes, btw) not being singletons is indeed not right.As said before, what you're seeing here is that
np.int64andnp.longlongare two different scalar types that have the same__repr__:It's pretty confusing IMO, but doesn't really matter much in practice.