python - 为什么 numpy.int32 不被识别为 int 类型

Question

我刚刚花了半个小时研究 statsmodels 的 SARIMAX 功能中的一个错误，我终于可以追溯到 numpy.int32 未能通过 int 类型检查这一事实。

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

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

编辑:我的问题是通过说明哪些技术限制或设计决策是这种行为的原因以及如何以 python 方式处理纯 python 的 int 和 numpy int32< 的情况来回答的 或 int64 类型可能会出现。

Answer 1

为什么 应该 numpy.int32 来自 int？ int 是一个特定的类。这是表示整数的一种方式。这并不意味着表示整数的每个类都应该派生自 int。 numpy.int32 具有不同的语义和不同的方法 - 例如，它具有像 0 维数组一样操作所需的大部分功能 - 而继承自 int 则不是对于实现 numpy.int32 特别有用。

在 Python 2 的某些构建中(仅限 Windows？)，numpy.int32 实际上是 int 的后代(在这些构建中也是 32 位的)，但是我相信这个设计决策可以追溯到 int 在溢出时执行像 numpy.int32 这样的环绕算法而不是提升到 long 的时候，并且当operator.index 不存在。这在当时是一个更合理的决定。

至于如何像对待int一样对待numpy.int32，numbers.Integral做的还不错，但是实现依赖于人们明确地使用 numbers.Integral register-ing 他们的类(class)，而人们通常不会这样做。 NumPy 直到 2014 才添加 register 调用，numbers.Integral 推出 6 年后。像 SymPy 这样的类似库仍然没有调用。

我发现 operator.index 是一个更好的检查:

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

operator.index 是类 int 类必须实现的钩子(Hook)，以使其实例可用作序列索引。这是比 int(x) 更严格的检查，后者接受 3.5 和 '3'。如果缺少此 Hook ，则会产生具体且容易察觉的影响，因此它比 numbers.Integral 支持更有可能出现。