Python 真的很糟糕吗？( 二 ) _Python

6returnmax
7
8arr = [5, 10, 3, 8, 15]
9max_num = find_max(arr)
10print("Maximum element in the list:", max_num)
这是用 Python 重写了上述的 C 程序。正如你所看到的，第 1-6 行定义了一个函数。第 4-5 行定义了`if`逻辑条件。这里的缩进（4个空格）告诉解释器，每个向右缩进到顶级构造的指令都属于该构造。与此同时，它还为程序员提供了可读性，以清楚地看到代码的边界。
一箭双雕，不是吗？Python 在这里做了一个合乎逻辑的决定，使用换行符（n）作为函数和逻辑语句的自然边界。有人可能会争论说，难以看到长度为 100 行的缩进块。我同意。当你的函数有 100 行时，会变得混乱，但在这种情况下，你应该考虑将代码拆分成更小的函数，以提高可读性。
没有强类型
很多人强调 Python 缺乏像 C、Java 或 Go 那样的强类型。是的， Python 缺乏类型，但其他动态编程语言如 Java、Ruby 或 Lua 也是如此。这是动态编程语言的特性。Python 缺乏基本类型是内在于其语言设计的。在 Python 中，一切都是对象，包括函数。要验证这个论点，你可以在 Python shell 中运行这个语句，使用任何数据类型。
1isinstance(1, object) # Returns True
你可以问，“为什么解释型语言没有强类型？”
答案是因为它们是解释型的。解释型语言一次性读取和执行程序。相比之下，编译型语言可以扫描程序以查看任何可能的类型不匹配，并在执行实际的编译二进制代码之前报告它们。在使用动态语言编写代码的最大好处是它的交互式反馈或REPL（读取-评估-打印循环）。Python 选择了这种方式，是因为动态程序以静态类型检查的代价更快地向用户提供反馈。
Python 的这种动态特性是否对项目有害？这取决于具体情况。如果一个人希望拥有一个没有单元测试的代码库，并且主要依赖编译器来捕获软件错误，那么 Python 对他们来说是一个正确的选择。在使用 Python 时，编写单元测试，执行异常处理，可以提高大型代码库的代码质量和可维护性。我们将在后面的部分中更详细地讨论这个问题。
Python 很慢
慢是一个相对的术语。对象 A 可能比对象 B 更快，但比对象 C 更慢。在进行比较时，我们应该更重视“对于给定用例的可接受性性能是什么？”而不是“Python 是否比 Java 慢？” 。例如，在 I/O 绑定任务中，程序等待来自连接网络的答案，而不是计算即时答案。而且并不是所有任务都受 CPU 的限制。大多数 Web 服务器很少受 CPU 限制。Python 在多个网络系统之间作为粘合系统表现非常出色，并充分利用了其异步 I/O 功能。
如果一个人的 Python 应用程序的关键路径需要 CPU 密集型操作，他们可以将其卸载到使用性能高、低级编程语言实现的 RPC 或 HTTP API 中。
因此，说 Python 慢就像确认“地球很大”，但在什么情况下呢？地球与人类或喜马拉雅山相比，确实很大。但与太阳、木卫一或土星等其他天体相比，它很小。在构建控制平面的背景下，Python 绝对是可以接受的，但可能不适合用于实现受 CPU 限制的高性能数据库方面。因此，在大多数用例中，说“Python 慢”都不是一个公正的评价。
Python 不适用于大型代码库
这是我经常听到从其他编程语言迁移到 Python 的开发人员的观点。
对此，我得到的进一步原因包括：

没有类型
没有好的 IDE 自动提供代码建议支持
难以调试逻辑错误

上文中，我们已经讨论了“无类型”这一说法。拥有良好的单元测试肯定可以帮助维护代码，并不是避免使用大型代码库的强有力原因。
十年前， Python 的 IDE 自动补全功能可能落后于静态类型语言如 C＃或 Java 。但现在不再如此。使用现代 IDE，如 PyCharm 和 VSCode，以及专用插件，我们几乎感觉不到任何差异。
由于代码中的多种原因，调试遗留企业项目中的逻辑错误是一场噩梦：

命名不当
函数违反单一职责原则（SRP）
共享全局状态
没有测试用例
模块/包臃肿

这些问题可以降低任何编程语言编写的项目的调试体验，而不仅仅是 Python 。如果你不同意我的观点，试着调试一个大规模编写得很糟糕的 Go 项目。你会讨厌你的生活。
最后，鉴于行业正在向微服务或无服务器函数等更小的计算单元迈进，大型代码库将在十年左右的时间逐渐转变为多个代码库。也许这些代码库可以愉快地使用 Python 。