4 个你不会在 Python 中看到的有用特性

Python 有许多很棒的特性——方便、范围广泛的强大库、有用的用户社区——但仍然缺少一些元素。在其他语言中发现的一些特性会使某些工作更容易，但它们不会很快出现在 Python 中。 以下是 Python 中目前不具备的四种常用语言特性。
其中至少有两个永远不会发生，而其他的最多是几年后的事。我们将看看是什么阻碍了这些功能，或者将它们包含在 Python 的未来版本中需要什么。 一些开发人员梦想使用静态类型编译为本机机器代码的 Python。
毕竟，灵活的类型是 Python 缓慢的根源，而静态类型会结束这种情况。静态类型还为程序员提供了强有力的保证，可以从他们的代码中得到什么。那么，有什么问题呢？ 虽然 Python 确实有类型提示，但它们旨在通过 linting 工具使该语言更易于在编辑时进行静态分析。
只有第三方项目（例如 pydantic）在运行时使用类型提示。 Python 运行时本身不使用类型提示。 PEP 484 中的一个明确目标，即类型提示的 Python 增强提案，是让类型提示永远是可选的。
，即使按照惯例。” 真正想要 Python 的静态类型版本的开发人员可以求助于 Cython 或 mypyc，但即使是这些项目也需要权衡取舍。就 Cython 而言，最大的性能提升来自使用纯 C 类型和结构，并减少了 Python 运行时的使用。
简而言之，很难在不牺牲其活力的情况下使 Python 编译得更快。拿走不需要动力的部分，将它们分开并加速它们要容易得多。 Python 的 lambda 表达式或匿名函数是有意限制的。
它们只允许将单个表达式（本质上是赋值操作中 = 符号右侧的任何内容）作为函数体。从 JavaScript 等语言开始使用 Python 的开发人员，其中多行匿名函数是常态，他们经常要求 Python 中的这个特性。 Python 的创建者 Guido van Rossum 很久以前就否定了 lambda 不是单个表达式的语法糖的想法。
他的立场最好地封装在 2006 年的一封电子邮件中，他在邮件中讨论了为什么多行 lambda 不是和在 Python 中不会是一个东西： 不用说，Python 中的多行 lambda 的未来看起来并不光明。 Global Interpreter Lock，或 GIL，长期以来一直是 Python 爱好者的眼中钉。 GIL 同步 Python 运行时中的活动，以序列化对对象的访问并管理全局状态。
GIL 的缺点是它使 Python 运行时在实践中成为单线程的。如果您想要真正的线程并行性，您需要启动 Python 解释器的离散副本并在每个副本上运行单独的线程。理论上，没有 GIL 的 Python 可以实现更高的并行性，从而提高性能。
那么，为什么不太可能呢？ 从 Python 中删除 GIL 的提议有很多。大多数会破坏向后兼容性，或者会使 Python 对单线程操作变慢，或者两者兼而有之。一项努力是，“GIL 切除术”项目带来了严重的性能损失。
Python 3.x 重新设计了 GIL 以提高其基线性能，但为了保持向后兼容性并没有将其删除。 由于这些担忧，GIL 对 Python 用户来说可能只是生活中的一个事实。
但仍有提高其性能的可能性。在 Python 运行时允许更好的并行性的一种方法是在单个进程中运行多个解释器。使该提议成为现实需要对 Python 的内部进行重大更改，包括重新编写 Python 的 C API 的部分内容。
许多第三方模块依赖于 C API，并且也需要更新。 较新的提案 PEP 684 扩展了多个解释器的想法，让每个子解释器使用自己的 GIL。在这种情况下，提议的更改还将允许战略性地共享需要在子解释器之间共享的对象。
在保持 Python 深受喜爱的灵活性的同时，一种行之有效的方法是使用即时编译器或 JIT。 JIT 编译涉及在运行时而不是提前分析代码，并根据代码在运行时表现出的行为有选择地或完全将其编译为机器代码。 Python 已经存在 JIT。
PyPy 是最常用和开发最完善的示例，擅长使长时间运行的服务器式应用程序在不修改程序源代码的情况下提高性能。但是 Python 的参考版本 CPython 会从某种 JIT 中受益吗？ 最近在 2021 年 Python 语言峰会上讨论的使 Python 更快的举措产生了一些类似的建议。当前的提议不是在 Python 中实现成熟的 JIT，而是为解释器添加自适应行为，以便在常见的特殊情况下更快地执行。
未来可能会有其他类型的 JIT 类型的专门化的空间，例如为真正的高速代码路径生成机器代码。但近期计划是进行改进以扩展现有解释器，而不是替换它..