[SciPy-user] Is numpy's argsort lying about its numpy.int32 types?

Rob Clewley rhc28@cornell....
Wed Apr 18 22:11:50 CDT 2007

Fair enough, but it does cause a *real* problem when I extract the
values from aa and pass them on to other functions which try to
compare their types to the integer types int and int32 that I can
import from numpy. Since the values I'm testing could equally have
been generated by functions that return the regular int type I can't
guarantee that those values will have a dtype attribute!

I have some initialization code for a big class that has to set up
some state differently depending on the type of the input. So, I was
trying to do something like this

if type(x) in [int, int32]:
    ## do stuff specific to integer x

but now it seems like I'll need

    isint = x.dtype == dtype('int32')
except AttributeError:
    isint = type(x) == int
if isint:
    ## do stuff specific to integer x

-- which is a mess! Is there a better way to do this test cleanly and
robustly? And why couldn't c_long always correspond to a unique numpy
name (i.e., not shared with int32) regardless of how it's implemented?
Either way it would be helpful to have a name for this "other" int32
that I can test against using the all-purpose type() ... so that I
could test something like

type(x) in [int, int32_c_long, int32_c_int]

Thanks in advance for the clarification!

More information about the SciPy-user mailing list