为什么numpy.int32不被识别为int类型 [英] Why is numpy.int32 not recognized as an int type

问题描述

我只花了半个小时来研究statsmodels的SARIMAX功能中的一个错误，最终我可以追溯到numpy.int32未能进行类型检查int的事实.

I just spent half an hour looking into a bug in statsmodels' SARIMAX functionality that I could finally trace back to the fact that numpy.int32 fails type checks for int.

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

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

Is there a way to circumvent this kind of issue without explicit type conversions? Should proper code even test for types and not check if a variable can safely be cast to a type?

我的问题是由以下原因解决的:导致此问题的原因是哪些技术限制或设计决定，以及如何以Python方式处理可能同时出现纯python int和numpy int32或int64类型的情况

My question is answered by an account of what technical limitations or design decisions are the cause of this behaviour and how to pythonically handle cases where both pure python's int and numpy int32 or int64 types might appear.

推荐答案

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

Why should numpy.int32 descend from int? int is a specific class. It is one way of representing integers. That doesn't mean that every class that represents integers should descend from int. numpy.int32 has different semantics and different methods - for example, it has most of the functionality needed to operate like a 0-dimensional array - and inheriting from int isn't particularly useful for implementing numpy.int32.

在某些版本的Python 2(仅Windows?)上，numpy.int32实际上会从int降级(在这些版本上也是32位)，但是我相信这一设计决定可以追溯到int在operator.index不存在时，执行类似于numpy.int32的环绕算术，而不是在溢出时提升为long.那时，这是一个更合理的决定.

On some builds of Python 2 (Windows only?), numpy.int32 actually will descend from int (which is also 32-bit on those builds), but I believe this design decision dates back to a time when int performed wraparound arithmetic like numpy.int32 instead of promoting to long on overflow, and when operator.index didn't exist. It was a more reasonable decision back then.

关于如何像对待int一样对待numpy.int32，numbers.Integral做得还不错，但是实现依赖于人们明确地register-用numbers.Integral设置他们的班级，而人们常常不这样做.不想这样做. NumPy直到 2014 6年后才添加register调用. >介绍.像SymPy这样的类似库仍然没有调用.

As for how to treat numpy.int32 like int, numbers.Integral does a sort of okay job, but the implementation relies on people explicitly register-ing their classes with numbers.Integral, and people often don't think to do that. NumPy didn't add the register calls until 2014, 6 years after numbers.Integral was introduced. Similar libraries like SymPy still don't have the calls.

我发现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支持更容易出现.

operator.index is the hook an int-like class has to implement to make its instances usable as a sequence index. It's a stricter check than int(x), which would accept 3.5 and '3'. Since there's a concrete, easily noticeable impact if this hook is missing, it's more likely to be present than numbers.Integral support.

这篇关于为什么numpy.int32不被识别为int类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！