Python 现在已经是两种非常相似的编程语言了_python有所见即所得的编程界面吗-CSDN博客

本文链接：https://blog.csdn.net/Trb201013/article/details/138113591

本文探讨了Python中的类型提示及其在非类型化和类型化Python中的应用，强调了基础设施代码与业务逻辑代码的区别，并指出两者结合的有效方式。同时，作者提到学习Python时的路径选择，包括如何利用现有资源进行全面学习和实战提升。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

现在使用 Python 的每个人都知道 Python 支持可选的类型提示，并且已经有一段时间了，这在社区中造成了一个小的分裂，有些人对类型提示完全不感兴趣，并且对语言部分进入新方向有点保守，有些人对我们不断发展的类型工具的潜力感到非常兴奋，以及还有很多中间状态的人，不完全确定在哪里以及如何最好地应用类型提示。

目前，Python 实际上是两种非常相似的编程语言，对于使用 Python 一段时间的人来说，这当然不足为奇。不过，可能令人惊讶的是，这实际上是一件好事。这些语言，让我们称它们为非类型化 Python 和类型化 Python，尽管共享一个非常大的共同基础，但它们在使开发人员使用它们解决问题的方式上存在根本不同。

请允许我提出一个思考代码的模型：基础设施代码和业务逻辑代码。基础设施代码是令人兴奋的、强大的代码，它公开了易于使用的接口来解决困难和棘手的问题，比如与浏览器对话（Flask）、与数据库对话（Django ORM、SQLAlchemy）、依赖注入框架（incant）、序列化（ cattrs）或定义类（attrs、数据类）。业务逻辑代码是枯燥乏味的代码，可让你在日常工作中解决问题并完成工单，基础设施代码的重点是启用和授权业务逻辑代码；业务逻辑代码为你的雇主、你的用户或任何使用你所写内容的人提供实际价值。基础架构代码是你正在使用的库，业务逻辑代码是你自己编写和部署的代码。

（请注意，与所有抽象一样，这种思考代码的方式是有漏洞的。你使用的库可能是其他库之间的一个简单层，因此具有业务逻辑代码的所有特征。如果你受雇于一个典型的软件公司开发人员职位你的工作代码库几乎肯定会有你为该代码库编写的基础设施代码。即便如此，但这种思考软件的方式非常有用。）

基础设施代码通常不可能在内部完全进行类型提示；Python 类型系统目前还没有，而且可能永远也不会强大到足以支持像 cattrs 和 attrs 这样的库需要做的操作类型。无类型 Python 的最大优势之一（也是让我首先接触 Python 的原因）是可用的基础结构代码可以提供非常友好和强大的 API。因此，非类型化 Python 过去一直是基础架构代码的绝佳选择；无类型的 Python 不太适合业务逻辑代码，这就是为什么从历史上看，软件开发人员很快就会抱怨维护用 Python 编写的大型系统，这是有理由的。

业务逻辑代码通常比基础设施代码简单得多，而且当今世界上有更多的代码；对于每个 SQLAlchemy 或 Django，可能有数百个（如果不是数百万个）代码库以简单的方式实际使用它。正因为如此，业务逻辑代码与类型化的 Python 非常匹配。使用类型化的 Python 为开发过程带来了很多好处，比如将整个类别的错误从运行时转移到类型检查时间、易于重构（这对于健康的代码库生命周期至关重要）、强大的编辑器支持（包括自动完成和稳健的列表引用，很好代码导航）并减少对测试的需求（这会大大增加需要编写和维护的代码量）。

为了使这种结合有效，我们需要基础设施代码不在内部进行类型提示，而是在代码边界提供类型提示接口。这正是生态系统的发展方向，值得注意的例子是 SQLAlchemy 2.0 和新一代 Web 框架，如 FastAPI。此外，随着 Python 类型系统的成熟，它将使一类基础设施代码能够完全类型化，但我的直觉是，最有趣的部分仍将是非类型化的。

至于为什么这是一件好事：如果你知道一个（类型化或非类型化的 Python），那么你学习另一个相对容易（无论如何比学习一种完全不同的语言容易一个数量级），并学习它将大大增强你作为软件开发人员的能力。

现在我们能否拥有一种同时擅长这两种语言？我不知道，但我真的不认为这会出现在像 Python 这样的语言中，我对几种不同的语言都有些精通，所以让我们看一下它们的情况：

JavaScript 似乎也有与 TypeScript 的分裂情况，尽管我不知道相对于基础设施代码和业务逻辑代码的情况，估计是一样的吧。
我已经将近十年没有接触 Java 了，但我曾经非常精通它，我使用的 Java 是彻头彻尾的业务逻辑语言，这很容易解释它在行业中的流行（因为行业中绝大多数工作都是为了编写业务逻辑代码）、所有主要库都有的糟糕接口，以及恐怖的是我看过一次的 ORM 代码，我认为 Java 实际上也是两种语言，但 Java 的基础设施很难使用，这就是为什么如果一位开发人员告诉我他们用 Python 编写了一个 ORM，我会兴奋地想要分享笔记，但当时如果一个开发人员告诉我他们用 Java 编写了一个 ORM，我会看看他们好像疯了一样。
我认为 Rust 通过其强大的宏系统为基础设施代码提供了一种非常有趣的方法。，我对 Rust 的了解还不够多，无法自信地发表评论，但我想你可以将 Rust 宏视为 Rust 之上的一种不同的基础结构语言，它输入（类型化）Rust 的方式对我来说特别优雅。

总之：类型化 Python 的加入对我们的社区来说是一件好事，而非类型化 Python 不会消失，我们只需要根据需求正确的使用，并努力将它们有效地结合起来。