[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

[Travis Oliphant]

Sebastian Haase wrote:
> This explains it - my specific function overloads only one of its two array 
> arguments (i.e. allow many different types)  - the second one must be a 
> C "int".    
> [(a 32bit int) - but SWIG  matches the "C signature" ] 
> But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
> But on 32bitLinux I get NPY_LONG because of that rule.
>
> My SWIG typemaps want to "double check" that a C function expecting c-type 
> "int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 
>   
Perhaps I can help you do what you want without making assumptions about 
the platform.   I'll assume you are matching on an int* signature and 
want to "translate" that to an integer array of the correct bit-width.  
So, you have a PyArrayObject as input I'll call self

Just check:

(PyArray_ISSIGNED(self) && PyArray_ITEMSIZE(self)==SIZEOF_INT)

For your type-map check.  This will work on all platforms and allow 
signed integers of the right type.

> I don't know what the solution should be  - but maybe the rule should be 
> changed based on the assumption that "int" in more common !?
>   
That's not going to happen at this point.  Besides in the Python world, 
the fact that Python integers are "long" means that the "long" is the 
more common 32-bit integer on 32-bit machines.

-Travis