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

Python有许多很棒的特性，如：方便、范围广泛的强大库、有用的用户社区等，但仍然缺少一些元素。在其他语言中发现的一些特性会使某些工作更容易，但它们不会很快出现在Python中。

以下是目前Python中没有的四种常用语言功能。其中至少有两个永远不会实现，而其他的最多是几年后的事。下面一起看看是什么阻碍了这些功能，或者将它们包含在Python的未来版本中需要什么。

1、Python的静态类型编译版本

一些开发人员梦想使用静态类型编译为本机机器代码的Python。毕竟，灵活的类型是Python缓慢的根源，而静态类型将结束这一点。静态类型还为程序员提供了强有力的保证，可以从他们的代码中得到什么。

虽然Python确实有类型提示，但它们旨在通过linting工具使该语言更易于在编辑时进行静态分析。只有第三方项目（例如pydantic）在运行时使用类型提示。Python运行时本身不使用类型提示。

PEP 484中的明确目标之一，即类型提示的Python增强提案，是让类型提示永远是可选的。“Python仍将是一种动态类型语言，作者不希望强制类型提示，即使按照惯例也是如此。”

真正想要Python的静态类型版本的开发人员可以求助于Cython或mypyc，但即使是这些项目也需要权衡取舍。对于Cython，最大的性能提升来自使用纯C类型和结构，并减少了Python运行时的使用。简而言之，很难在不牺牲其活力的情况下让Python编译得更快。拿走不需要动力的部分，将它们分开并加速它们要容易得多。

2、多行lambda

Python的lambda表达式或匿名函数是有意限制的。它们只允许将单个表达式（本质上是赋值操作中=符号右侧的任何内容）作为函数体。从JavaScript等语言开始使用Python的开发人员，其中多行匿名函数是常态，他们经常要求Python中的这个特性。

Python的创建者Guido van Rossum很久以前就否定了lambda不是单个表达式的语法糖的想法。他的立场最好地概括在2006年的一封电子邮件中，他在邮件中讨论了为什么多行lambda在Python中不是也不会成为一个东西：

多行lambdas会给Python增加很少或没有实际的功能或表达能力，并且会以使其成为一种可读性较差的语言为代价。（可读性是Python最关心的问题。）

没有提供可以与Python的其余空格敏感设计优雅集成的可用语法。

将多行lambda转换为成熟的函数并不费力，无论如何，van Rossum建议将其作为“多行lambda”场景的用例。

不用说，Python中的多行lambda的未来看起来并不乐观。

3、没有GIL的Python

Global Interpreter Lock(GIL)长期以来一直是Python爱好者的眼中钉。GIL同步Python运行时中的活动，以序列化对对象的访问并管理全局状态。GIL的缺点是它使Python运行时在实践中是单线程的。如果想要真正的线程并行性，需要启动Python解释器的离散副本并在每个副本上运行单独的线程。理论上，没有GIL的Python可以允许更大的并行性，从而提高性能。那么，为什么不太可能呢？

从Python中删除GIL的提议有很多。大多数会破坏向后兼容性，或者会使Python对单线程操作变慢，或者两者兼而有之。一项努力，“GILectomy”项目带来了严重的性能损失。Python 3.x对GIL进行了重新设计以提高其基线性能，但并未将其删除以保持向后兼容性。

由于这些担忧，GIL可能只是Python用户的生活中的一个事实。但是有提高其性能的可能性。在Python运行时允许更好的并行性的一种方法是在单个进程中运行多个解释器。使该提议成为现实需要对Python的内部进行重大更改，包括重新编写Python的C API的部分内容。许多第三方模块依赖于C API，也需要更新。

较新的提案PEP 684扩展了多个解释器的想法，让每个子解释器使用自己的GIL。在这种情况下，提议的更改还将允许战略性地共享需要在子解释器之间共享的对象。

4、一个Python原生的JIT编译器

在保持Python深受喜爱的灵活性的同时，一种行之有效的方法是使用即时编译器或JIT。JIT编译涉及在运行时而不是提前分析代码，并根据代码在运行时表现出的行为有选择地或完全将其编译为机器代码。

Python已经存在JIT。PyPy是最常用和开发最好的示例，擅长使长时间运行的服务器式应用程序在不修改程序源代码的情况下提供更高的性能。但是Python的参考版本CPython会从某种JIT中受益吗？

最近在2021年Python语言峰会上讨论的使Python更快的举措产生了一些类似的建议。当前的提议不是在Python中实现成熟的JIT，而是为解释器添加自适应行为，以便在常见的特殊情况下更快地执行。将来可能会有其他类型的JIT类型的专门化的空间，例如为真正的高速代码路径生成机器代码。但近期计划是进行改进以扩展现有解释器，而不是替换它。