Repository navigation
BUG: np.int_ and np.intc / np.longlong have the same __name__ but are different #9799
Description
On windows 7:
>>> np.cint, np.cint is np.int32
(numpy.int32, False)
>>> np.int_, np.int_ is np.int32
(numpy.int32, True)On 64-bit linux:
>>> np.int_, np.int_ is np.int64
(numpy.int64, True)
>>> np.longlong, np.longlong is np.int64
(numpy.int64, False)(original title: intc displays wrong class name)
The string representation of numpy.intc is <class 'numpy.int32'>. This would fine if this were true--just a name pointing to the same object. But at least on Windows 7, numpy.intc is not the same object as numpy.int32; it's not even a subclass. This is very confusing for debugging objects of this type, as objects inexplicably fail an isinstance test.
Could one of these two small changes be made:
- Either make
intcjust be another name pointing to the object behindint32 - Or make
intcprint out<class 'numpy.intc'>
Activity
drhagen commentedon Oct 1, 2017
This is related to #6295 and others linked there.
eric-wieser commentedon Oct 1, 2017
This isn't because the dtypes aren't singletons, as the linked issue describes. The problem is that
int32refers tolong, andcintrefers toint- but on windowslongandintare both 32-bit:Really, the issue is that we have a leaky abstraction, where internally we work in terms of
char,short,int,long,long long, but to the user we showint8int16int32int64. On any platform, two of these are going to have the same name.eric-wieser commentedon Oct 1, 2017
Because
np.intcis defined to mean a Cint, this would requirenp.int32to refer tointas well. This is fine, but now you breaknp.int_(long) in the same way ascintis currently broken, which also prints asnp.int32This is tricky, because now
np.int32will print out like that toodrhagen commentedon Oct 1, 2017
It seems strange that these objects would be so tightly coupled that the
__str__method couldn't be swapped out, but not so tightly coupled that the object itself can't be swapped out. But I don't know anything about the C code, so I'll just accept that there is something difficult going on.I did find that
numpy.intp is numpy.int64returnsTrue.eric-wieser commentedon Oct 1, 2017
If all you want to do is change the string, here's your task: write a function to replace the one in the pseudocode below.
Can you propose a better way to generate names? One option would be to simply
return c_name, but I'd argue that seeing the number of bits in therepris usefuldrhagen commentedon Oct 2, 2017
Maybe this happens to late and this is the problem, but somewhere the name it is supposed to ultimately have on the
numpymodule is assigned (e.g.setattr(numpy, 'intc', intc_object)). It would be nice is the same code that assigned the attribute name also assigned or reassigned the__repr__string. Something like:setattr(numpy, 'intc', update_repr(intc_object, 'intc'))[-]`intc` displays wrong class name[/-][+]BUG: np.long and np.intc / np.longlong have the same `repr`[/+][-]BUG: np.long and np.intc / np.longlong have the same `repr`[/-][+]BUG: np.int_ and np.intc / np.longlong have the same `repr`[/+][-]BUG: np.int_ and np.intc / np.longlong have the same `repr`[/-][+]BUG: np.int_ and np.intc / np.longlong have the same __name__ but are different[/+]eric-wieser commentedon Dec 2, 2017
I've updated your description so that we can point to this as the canonical bug report
2 remaining items
Work around Numpy formatting glitch in doctest