为什么numpy.int32无法识别为int类型
问题内容：
我只花了半个小时来研究statsmodels的SARIMAX功能中的一个错误，最终我可以追溯到numpy.int32无法通过类型检查int的事实。
>>> import numpy as np
>>> foo = np.int32(3)
>>> isinstance(foo, int)
False
没有显式的类型转换，是否有办法避免此类问题？正确的代码是否应该测试类型，而不检查变量是否可以安全地转换为类型？
编辑：我的问题是由以下原因解决的：什么技术限制或设计决策是造成此问题的原因，以及如何以Python方式处理可能同时出现纯pythonint和numpyint32或int64类型的情况。
问题答案：
为什么 要
numpy.int32从何而来int？int是一个特定的类。它是表示整数的一种方法。这并不意味着每个代表整数的类都应从继承int。numpy.int32具有不同的语义和不同的方法-
例如，它具有像0维数组一样进行操作所需的大多数功能-并且从int实现继承不是特别有用numpy.int32。
在Python
2的某些版本（仅Windows？）上，numpy.int32实际上会从int该版本降级（在这些版本上也是32位），但我相信，此设计决定可以追溯到int执行环绕式算法之时，numpy.int32而不是升级long为溢出时。
，以及何时operator.index不存在。那时，这是一个更合理的决定。
至于如何对待numpy.int32像int，numbers.Integral确实一种好的工作，但实现依赖于人明确register-ing他们班有numbers.Integral，人们通常不会想到这样做。NumPyregister直到被引入6年后的2014年才添加通话numbers.Integral。像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和更严格的支票'3'。如果缺少此挂钩，则会产生具体且容易注意到的影响，因此比numbers.Integral支持更容易出现。
