`numpy.histogram` is returning an array of `int64`, which is breaking compatibility with bindings/C wrapper code

Due to this change:

https://github.com/numpy/numpy/commit/34b582aadae8272e7b7209f7a05594e9258ba217#diff-9d44603693b9544b900e135a203b3ae2R180

    # Histogram is an integer or a float array depending on the weights.
    if weights is None:
        ntype = np.dtype(np.intp)  # <---
    else:
        ntype = weights.dtype

numpy.histogram is choosing intp as the return type for the histogram values. This is breaking compatibility with wrapper code that expects simple ints (int32 are fine, as are python long, but usually C wrapper code can’t handle numpy.int64). What is worse is that the behaviour is platform-dependent (i.e., it keeps working on 32-bit platforms).

Could it be changed to simply use int as dtype (i.e., would use numpy.int32)?

[rkern]

You generally want to use PyNumber API instead of the PyLong API if you want to be able to use numpy scalar objects. You don’t need to use the numpy API.

[jaimefrio]

In a 64 bit system you could have an input to histogram having more than 2**31 - 1 identical values, which would result in an int32 overflowing. So I think it is pretty much uncontroversial that the right thing to do is to go with np.intp.

It’s hard to tell without knowing more details, but the issue here seems to be that your wrapper code is not ready to work on 64 bit systems, and you will need to adapt it to fix that, not expect NumPy to sacrifice correctness for your convenience.