Python不会在编译时检查类型,因为它不能,至少在某些情况下。但有没有人提出一种机制来根据用户的额外注释进行编译时类型检查?像pylint一样使用作者的额外保证?我想的是:
#guarantee(argument=int, return_type=int)
def f(x):
return x + 3
#guarantee(argument=int, return_type=str)
def g(x):
return "%d times" % x
y = f(6)
# works, z = "9 times"
z = g(y)
# error
a = f(z)
此检查器会解释每个函数上方的注释,意识到f(x)
只应接受int
,但z来自g(x)
,因此它是str
。是否有任何产品与此类似?
答案 0 :(得分:2)
PEP 3107(最近在去年的某个时候),它引入了变量和函数的注释。不幸的是(从pep的数量可以看出)这只适用于Python 3.x所以你编写的任何检查器(甚至代码)都只是Python 3(这真的不是坏事) )。
你提到了pylint所以我假设你实际上并不想在编译时运行检查,而是在编译后检查。这将是一个很棒的工具,可以在code-quality mailing list进行讨论。
答案 1 :(得分:1)
我认为您丢失的关键字是decorator
。
您可以编写自己的装饰器来执行以下操作:
@check(bar=int)
foo(bar):
pass
您可以看到示例实现here。虽然这对于编译检查当然是无效的,因为它是在运行时完成的。
答案 2 :(得分:0)
我不确定这是如何比Python中现有的运行时机制有显着改进的。例如,
def f(x):
if not isinstance(x, int):
raise TypeError("Expected integer")
return x + 3
def g(x):
return "%d times" % x
# Works.
y = f(6)
z = g(y)
# Fails, raises TypeError.
a = f(z)
换句话说,在没有注释Python中每个对象的每个函数和每个方法的情况下,很难静态地确定f
或g
的返回类型是什么。我怀疑沿着这些线的任何静态检查器都没有任何价值。
即使您在函数中添加了返回类型描述符,这真的是一个保证吗?它看起来很像文档可能无法与代码一起更新,导致后来由于错误的假设导致更加隐蔽的错误。