当这样一个基本的，有效的，我认为是平凡的问题被提出时，看到如此激烈的讨论真是令人震惊。

有些人指出，针对int(和long)的类型检查可能会在遇到大十进制数的情况下出错。完全正确。

有些人指出，你应该“只做x + 1，看看是否会失败”。好吧，一方面，这也适用于浮点数，另一方面，很容易构造一个肯定不是很数字的类，但以某种方式定义了+运算符。

我不同意许多大力宣称你不应该检查类型的帖子。好吧，GvR曾经说过这样的话，在纯理论中，这可能是对的，但在实践中，isinstance通常是有用的(那是一段时间前，没有链接;你可以在类似这篇文章中阅读GvR对相关问题的看法)。

有趣的是，很多人似乎认为OP的意图是检查给定x的类型是否为数值整数类型——我所理解的是我通常在使用OP的话时的意思:x是否代表整数。这是非常重要的:比如问别人他们想选多少个项目，你可能想检查你得到的是一个非负整数。这样的用例比比皆是。

在我看来，重要的是要看到(1)类型检查只是程序正确性的一种度量，而且通常是相当粗略的，因为(2)通常是有边界的值有意义，而越界的值毫无意义。有时，只有一些间歇值是有意义的——比如考虑所有的数字，在给定的情况下，只有那些实数(非复数)、整数是可能的。

有趣的是，似乎没有人提到检查x == math。楼层(x)。如果这应该给出一些大的十进制类的错误，那么也许是时候重新思考OOP范式了。还有PEP 357考虑了如何使用不那么明显是整数但肯定是整数的值作为列表索引。我不确定我是否喜欢这个解决方案。

下面是这里提到的不同方法的总结:

Int (x) == x 尝试x = operator.index(x) isinstance (x, int) isinstance (x, numbers.Integral)

下面是它们如何应用于各种具有整数值的数值类型:

你可以看到它们不是100%一致的。Fraction和Rational在概念上是相同的，但是一个提供了.index()方法，而另一个没有。复杂类型不喜欢转换为int，即使实部是整数，虚部是0。

(np.int8|16|32|64(5)表示np.int8(5)， np.int32(5)等行为相同)

在这里找到了一个关于SO本身的相关问题。

Python开发人员倾向于不检查类型，而是执行特定于类型的操作并捕获TypeError异常。但如果你不知道类型，那么你有以下。

>>> i = 12345
>>> type(i)
<type 'int'>
>>> type(i) is int
True

一个简单的方法是直接检查除以1的余数是否为0。

if this_variable % 1 == 0:
    list.append(this_variable)
else:
    print 'Not an Integer!'

你也可以使用str.isdigit。尝试查找帮助(str.isdigit)

def is_digit(str):
      return str.isdigit()

如果你要这么做，那就这么做

isinstance(<var>, int)

除非你用的是python2。X是你想要的

isinstance(<var>, (int, long))

不要使用type。在Python中，这几乎从来都不是正确的答案，因为它阻碍了多态性的所有灵活性。例如，如果你继承int类型，你的新类应该注册为int类型，这种类型是不行的:

class Spam(int): pass
x = Spam(0)
type(x) == int # False
isinstance(x, int) # True

这遵循了Python的强多态性:您应该允许任何行为类似int型的对象，而不是强制它是int型。

BUT

然而，经典的Python心态是请求原谅比请求许可更容易。换句话说，不要检查x是否是整数;假设它是，如果不是，则捕获异常结果:

try:
    x += 1
except TypeError:
    ...

这种心态正慢慢被抽象基类的使用所取代，抽象基类允许您准确地注册对象应该具有的属性(添加哪些属性?乘?加倍?)通过使它继承一个特殊构造的类。这将是最好的解决方案，因为它将允许那些具有必要和足够属性的对象，但你必须阅读如何使用它的文档。