【CSDN 编者按】有业界人士认为，如今的 Python 可以看作是 “拥有同一个名字的两种非常相似的编程语言”。这两种语言可以称之为非类型化 Python 和类型化 Python。
原文地址：https://threeofwands.com/python-is-two-languages-now-and-thats-actually-great/
未经授权，禁止转载！
作者 | Tin 译者 | 邓晓娟
出品 | CSDN（ID：CSDNnews)
众所周知，Python 在 3.6+ 版本的时候就加入了对“类型提示”的支持。这些“类型提示”可以说是一种新的语法，用于声明一个变量的类型。通过声明变量的类型，编辑器和一些工具可以提供更好的支持。
但实际上，这个新的能力让 Python 社区中出现了一个小的分裂：有些人对类型提示完全不感兴趣，对于 Python 语言似乎进入到一个新的领域而有所防备；另一部分人对不断发展的类型工具的潜力感到非常兴奋，迫不及待地想要尝试。而绝大多数人处于中间，并不完全清楚在哪里、以及如何更好地使用“类型提示”。
有业界人士认为，如今的 Python 可以看作是 “拥有同一个名字的两种非常相似的编程语言”。这两种语言可以称之为非类型化 Python 和类型化 Python。尽管这两种语言共享着一个非常大的共同基础，但他们在帮助开发者解决问题的方式上有着根本的不同。
业务逻辑代码和类型化 Python 更配
大家都知道，代码中有基础设施代码和业务逻辑代码。那我们可以设想一种思考代码的模式：
基础设施代码是很强大的代码，它暴露出易于使用的接口，负责解决困难和棘手的问题，如与浏览器对话（Flask）与数据库对话（Django ORM，SQLAlchemy），依赖注入框架（incant），序列化（cattrs）或定义类（attrs，dataclasses）；
业务逻辑代码是枯燥无味的，但它能让你在日常工作中解决问题，完成任务和冲刺；
基础设施代码的重点是启用和授权业务逻辑代码，业务逻辑代码为公司、用户或任何使用你写的东西的人提供实际价值；
基础设施代码是你正在使用的库，业务逻辑代码是你编写和部署的代码。
值得注意的是，这种思考代码的方式就像所有抽象一样，是有漏洞的。你使用的一个库可能是其他库之间的一个简单层，因此具有业务逻辑代码的所有特征；如果你是一个典型的软件开发者，那你的工作代码库基本上都会有你为这个代码库编写的基础设施代码。即便如此，如上的思考软件的方式还是可以在大部分时候套用，便于我们理解代码的。
基础设施代码通常不可能在内部进行完全的类型提示。至少 Python 的类型系统里还不行，而且可能永远都不会强大到足以支持像 cattrs 和 attrs 这样的库所需要的操作类型。非类型化 Python 的最大优势之一，是可用的基础结构代码可以提供惊人且强大的 API，所以，无论是从前还是现在，非类型化 Python 对基础设施代码来说是非常友好的。而非类型化 Python 对于业务逻辑代码来说就不是很友好了，这就是为什么许多软件开发者经常抱怨基于 Python 的大型系统维护困难的原因。
业务逻辑代码通常比基础代码结构简单得多，而且现在有成百上千，甚至数百万的代码库都在以简便的方式去使用 SQLAlchemy 或 Django。正因如此，业务逻辑代码和类型化的 Python 非常匹配：比如将整个类别的 Bug 从运行时间转移到类型检查时间，易于重构，这对一个健康的代码库生命周期至关重要；还有强大的编辑器支持，包括自动完成和稳健地列出引用、良好的代码导航；以及减少对测试的需要，毕竟测试大大增加了需要编写和维护的代码量。它是支持面向对象的，很多情况下使用面向对象编程会使得代码更加容易扩展，并且可维护性更高。
那么，如何让业务逻辑代码和类型化 Python 的结合发挥它的作用？
首先，我们需要基础设施代码在内部不进行类型提示，而似乎在代码边界提供类型的接口。这正是生态系统的发展方向，就像 SQLAlchemy 2.0 和新一代的网络框架（如 FastAPI）的案例一样。另外，随着 Python 类型系统的成熟，它将会使一类基础设施代码完全类型化。
这对开发者来说是一件好事。试想一下，当你了解了类型化/未类型化的 Python 的其中一个之后，那么你学习另一个就相对容易，至少相对于学习一种完全不同的语言要容易许多。而且学习它将大大增强开发者本身的能力。
类型化 Python 的出现是件好事
有人可能要问了：有没有一门既适合基础设施代码、又能让业务逻辑代码可扩展性/可维护性更高的代码？虽然不敢断言，但业内人士表示，对于 Python 这样的语言来说几乎是不可能的。可以参考下其他语言的情况：
JavaScript 似乎也有与 TypeScript 分裂的情况，相对于 infra 与业务逻辑代码。应该和 Python 的情况差不多；
Java 可以算是一种彻头彻尾的业务逻辑语言，这就很好地解释了它在业界的受欢迎程度，但所有的库的接口都比较拉跨。基本可以认为 Java 实际上也是两种语言，只不过基础设施 Java 非常难操作。这就是为什么如果一个人说他用 Python 写了一个 ORM，大家可能会很兴奋地想要去看看；但如果一个人说他用 Java 写了一个 ORM，很多人可能会用看疯子一样看着他们；
Rust 在处理基础设施代码方面，有一个非常有趣的方法，它们有强大的宏系统。可以把 Rust 宏看成是 Rust 上的一种不同的基础设施语言。可以说，它融入（类型化）Rust 的方式特别优雅。
总地来说，类型化 Python 的出现对于社区来说是件好事，而非类型化 Python 也不会消失。我们只需要了解每种类型的正确定位，并努力地将它们有效地结合起来，就可以更好地为我们所用。