Python缺乏静态类型如何影响大型项目的可维护性和可扩展性？
在阅读了这个非常有启发性（虽然有点争论）的提问后，我想了解一下大家在用Python编写大型项目时的经验。随着项目规模的扩大，事情会变得难以管理吗？这个问题让我一直对Java保持关注。因此，我特别想知道关于Java和Python在大型项目中的可维护性和可扩展性的比较，最好是有根据的比较。
8 个回答
试着在一个大型的、动态类型的框架中，追踪一个看起来有问题的对象的来源。这个框架里有很多依赖注入（IoC）或者其他设计模式，导致这个对象无法直接在调用栈上找到。
现在，试着在一个静态类型的语言中做同样的事情。
除非这个对象的类型在使用的地方有清晰的文档说明（比如通过类型注解，就像Python的类型安全库那样），或者在调用栈的某个地方有说明，否则要推断它的来源几乎是不可能的。我是根据自己的经验说的，因为我曾经尝试调试BuildBot框架的部分内容。这需要在框架中进行大量的文本搜索，甚至使用像PyDev、Komodo和Wingware这样的高级开发工具。
我并不怀疑在动态语言中施加一些类型约束是可能的，但缺乏任何标准化似乎让调试大型现有框架的工作变得更加困难。
补充：自2014年以来，Guido添加了PEP484、MyPy和typing模块。这让我的大型项目维护体验变得好很多。
强类型语言通常会产生更少的错误，而在Python 3.11中加入了类型提示，这点和TypeScript很像。
弱类型语言适合快速开发，有时候能够快速尝试新功能更为重要。
这里没有唯一的解决方案——选择适合你工作的工具就好。
我在一个大规模的商业项目上工作，这个项目是用Python做的。我粗略估计一下，大概有5000个文件，每个文件大约500行代码，总共大约有250万行Python代码。要知道，这个项目的复杂程度可能相当于其他语言中1000万行以上的代码。我没有听到过任何工程师、架构师或经理抱怨Python代码难以维护。从我们的问题追踪系统来看，我也没有发现有什么系统性的问题是通过静态类型检查可以避免的。实际上，几乎没有因为对象类型使用不当而产生的错误。
我认为这是一个很好的学术课题，可以实证研究为什么静态类语言似乎没有想象中那么重要。
关于可扩展性，我们刚刚在产品中添加了第二个非SQL数据库，建立在第一个数据库之上。与类型检查没有任何问题。首先，我们设计了一个足够灵活的API，以便能够预见不同的底层实现。我认为动态语言在这方面是有帮助的，而不是障碍。当我们进入测试和修复错误的阶段时，我们遇到的错误和任何语言的开发者都会遇到的错误是一样的。例如，内存使用问题、一致性和引用完整性问题、错误处理问题。我觉得静态类型检查对这些挑战没有太大帮助。另一方面，我们从动态语言中受益匪浅，因为我们能够在运行时注入代码或进行简单的修补。这样我们可以快速测试我们的假设并展示我们的修复。
可以说，我们100多名工程师中大多数人都很高兴并且在使用Python时很高效。用静态类型语言在同样的时间内以同样的质量构建同样的产品，对我们来说可能是不可想象的。