动态类型化的缺点之一是无法在运行时知道类型。但是在我看来，给定完整的源代码，应该有某种（可能尚未开发）测试代码中每种情况的方法，因此运行时崩溃的可能性较小。什么时候不可能？
类型推断可能不明确的另一种情况是，如果整个程序由
def foo(x):
return x * 3
在这种情况下，实现的任何类型__mul__都可以作为此类型的候选。出建宏，这包括int，float，complex，long，list，tuple，string，unicode，bytearray，buffer，等。
如果在前面的示例中添加更多上下文，则类型推断将如何工作变得更加清楚：
def foo(x):
return x * 3
y = "hello"
foo(y) #=> "hellohellohello"
在这种情况下，我们可以简单地通过使用复制传播来执行此检查，在复制传播中y，我们知道传入的是包含的"hello"，foo因此，在这种情况下，foo(x)可以推断为foo(x: string) -> string。
不幸的是，正如@Pablo所指出的，只要我们添加一个条件，就可以再次推断类型：
def foo(x):
return x * 3
y = "hello"
if some_other_function():
y = 3
foo(y) #=> 9 or "hellohellohello"???
在这种情况下，我们可以说的最好是astring或an int。由于添加了此条件（基于的结果some_other_function()），我们不知道是否会达到foo(y)，如果这样做，我们将不知道y将是哪种类型。
在JavaScript（另一种鸭子类型的语言，其类型系统比Python弱）中，诸如Facebook的Flow之类的工具可以执行合理的静态类型检查。Flow支持类型注释，以进一步帮助其分析，但如果没有它们，效果很好。同样，Python 3中的函数注释当然可以帮助这种静态分析。即使没有注释，类型检查工具似乎已经存在（请参阅：https : //stackoverflow.com/questions/35470/are-there-any-static-analysis-tools-for-python）。一个例子是PySonar2。
最后，Python当然可以执行此推断。在这种情况下，解释Python的事实没有任何意义。OCaml具有编译器附带的解释器，但OCaml是静态类型的语言。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句