python弱语言类型的特征_弱类型语言的优点（和缺点）是什么？

static类型化的优点是在编译时捕获了所有类的错误，这些错误无法到达运行时。例如，如果您有一个静态类型的类或接口作为函数参数，那么您很可能不会意外地传入一个错误类型的对象(没有显式和不正确的强制转换，也就是说)。

当然，这并不能阻止您传入正确类型的错误对象，或者一个接口的实现，在这个接口中，您给了它正确的函数，但是它们做了错误的事情。此外，如果您有100%的代码覆盖率，比如PHP/Python/etc，谁会关心您是在编译时还是在运行时捕获错误呢？

就我个人而言，我在有静态输入的语言中度过了愉快的时光，在没有静态输入的语言中度过了愉快的时光。这很少是一个决定性的问题，因为我从来没有在两种语言之间做出选择，除了它们的类型，它们是相同的，通常还有更重要的事情要担心。我确实发现，当我使用静态类型语言时，我故意“依赖编译器”，试图以这样一种方式编写代码，如果它是错误的，它将不会编译。例如，有些重构可以通过在一个地方进行更改来执行，然后修复导致的所有编译错误，重复执行直到完成编译。通过多次运行完整的测试套件来执行相同的操作可能不太实际。但IDE用其他语言自动完成相同的重构，或者测试快速完成，这并非闻所未闻，所以这是一个什么是方便的问题，而不是什么是可能的问题。

除了方便性和编码风格偏好之外，那些关注代码正确性的人是那些致力于正式证明代码正确性的人。我无知的印象是，静态类型演绎可以做大部分(但不是全部)的工作，显式静态类型做，并节省相当大的磨损键盘。因此，如果静态类型迫使人们以一种更容易证明的方式编写代码，那么从POV中很可能会有一些东西。我说“如果”：我不知道，而且似乎大多数人都不会证明他们的静态类型代码。

动态更改变量类型等

我认为这有可疑的价值。做一些事情总是很吸引人(Python/Django)：user = request.GET['username']

# do something with the string variable, "user"

user = get_object_or_404(User,user)

# do something with the User object variable, "user"

但实际上，一个函数中的不同事物应该使用相同的名称吗？也许 吧。可能不会。”例如，在静态类型语言中，不鼓励将整型变量用于其他事情。不需要考虑简洁、描述性的变量名的愿望，可能95%的时间不应该覆盖对明确代码的渴望。。。

顺便说一下，通常弱类型意味着发生隐式类型转换，而强类型意味着不发生隐式类型转换。根据这个定义，就算术类型而言，C是弱类型的，所以我认为这不是你的意思。我认为人们普遍认为完全强类型比帮助更麻烦，而“完全弱类型”(任何东西都可以转换成其他东西)在大多数语言中都是荒谬的。因此，问题是在代码变得难以理解之前，可以容忍多少和哪些隐式转换。在C++中，也看到在决定是否实现转换运算符和非显式一个ARG构造函数的过程中存在的困难。