为什么是数字.int32不被识别为int类型

Question

我只花了半个小时研究了statsmodels的SARIMAX功能中的一个bug，最终我可以追溯到数字.int32int类型检查失败

>>> import numpy as np
>>> foo = np.int32(3)
>>> isinstance(foo, int)
False

有没有办法在没有显式类型转换的情况下规避这种问题？ 正确的代码是否应该测试类型，而不是检查变量是否可以安全地转换为类型？在

编辑：我的问题的答案是什么技术限制或设计决策是导致这种行为的原因，以及如何pythonical处理纯python的int和numpyint32或int64类型可能出现的情况。在

Answer 1

为什么应该从^{下降？int是一个特定的类。这是表示整数的一种方法。这并不意味着每个表示整数的类都应该从int开始。numpy.int32具有不同的语义和不同的方法（例如，它具有像0维数组一样操作所需的大部分功能），从{}继承对于实现numpy.int32并不是特别有用。在

在Python2的某些版本上（仅限Windows？），实际上，numpy.int32将从int（在那些构建中也是32位的），但我相信这个设计决定可以追溯到int执行了类似numpy.int32的环绕算法，而不是在溢出时提升为long，并且{}不存在。那是一个比较合理的决定。在

至于如何将numpy.int32视为int，numbers.Integral做得还不错，但实现依赖于人们显式地register-用numbers.Integral来处理他们的类，而人们通常不这么想。NumPy直到register调用才添加，直到numbers.Integral引入了numbers.Integral之后的2014。类似的图书馆，如SymPy仍然没有电话。在

我发现operator.index是一个更好的检查方法：

try:
    real_int = operator.index(some_intlike_thing)
except TypeError:
    # Not intlike.
    do_something_about_that()

operator.index是类int类必须实现的钩子，以使其实例可用作序列索引。这是一个比int(x)更严格的检查，它将接受3.5和{}。因为如果缺少这个钩子，会有一个具体的、很容易被注意到的影响，所以它比numbers.Integral支持更可能存在。在

Answer 2

__mro__列出类的继承堆栈：

np.int32.__mro__
Out[30]: 
(numpy.int32,
 numpy.signedinteger,
 numpy.integer,
 numpy.number,
 numpy.generic,
 object)

int.__mro__
Out[31]: (int, object)

对于基本阵列：

^{pr2}$

此堆栈上类的isinstance返回True：

isinstance(x[0], np.int32)
Out[37]: True    
isinstance(x[0], np.number)
Out[38]: True    

int不在此堆栈上：

isinstance(x[0], int)
Out[39]: False    
isinstance(x[0], object)
Out[40]: True

item从其numpy包装中提取一个值：

isinstance(x[0].item(), int)
Out[41]: True

@kazemakase建议使用numbers模块：

isinstance(x[0], numbers.Integral)
Out[47]: True