你不会在Python中看到的4个有用的特性
以下是为什么其他语言中的一些流行功能--包括静态类型、多行lambdas和本地JIT编译--对于Python来说是不可能的，至少目前是这样。
Python 有许多伟大的特性--方便、广泛的强大的库、有用的用户社区--但仍缺少一些元素。在其他语言中发现的一些功能会使某些工作更容易，但它们不会很快出现在Python中。
下面是四种普遍要求的语言特性，它们目前不在 Python 的计划之内。其中至少有两个永远不会实现，而其他的，充其量也就是几年后的事情。我们将看看是什么阻碍了这些特性的实现，或者说要在未来的Python版本中包含它们需要做些什么。
不对：一个静态类型的、已编译的 Python 版本
一些开发者梦想着一个使用静态类型的Python来编译成本地机器代码。毕竟，灵活的类型是Python缓慢的来源，而静态类型将结束这种情况。静态类型也为程序员提供了强有力的保证，使他们能够从他们的代码中得到什么。那么，问题出在哪里？
虽然Python确实有类型提示，但它们是为了在编辑时使语言更适合于静态分析，通过提示工具来实现。只有第三方项目 (如pydantic) 在运行时使用类型提示。Python 运行时本身并不使用类型提示。
在 PEP 484 中的一个明确目标，即关于类型提示的 Python 增强建议，是让类型提示永远是可选的。"Python 仍将是一种动态类型的语言，作者不希望将类型提示变成强制性的，即使是约定俗成的。"
真正想要静态类型的Python版本的开发者可以求助于Cython或mypyc ，但即使是这些项目也是有取舍的。在Cython中，最大的性能提升来自于使用纯C类型和结构，以及减少对Python运行时间的使用。简单地说，在不牺牲Python的动态性的情况下，很难让它编译得更快。把不需要动态性的部分分离出来，然后提高它们的速度，这要容易得多。
不对：多行lambdas
Python 的 lambda 表达式，或匿名函数，被刻意限制。它们只允许一个表达式（本质上，在赋值操作中= 符号右边的任何东西）作为函数体。从JavaScript等语言来到Python的开发者，在那里多行匿名函数是一种常态，他们经常要求在Python中提供这种功能。
Python 的创造者 Guido van Rossum 很久以前就否定了 lambda 除了是单一表达式的语法糖之外的任何想法。他的立场在2006年的一封电子邮件中得到了最好的概括，在那里他讨论了为什么多行lambdas在Python中不是也不会成为一个东西：
- 多行lambdas几乎没有给Python增加任何实际的能力或表现力，而且会以使它成为一种可读性较差的语言为代价。(可读性是Python的首要问题)。
- 目前还没有提供可用的语法，可以与Python的白色空间敏感设计的其他部分优雅地整合。
- 将多行lambda转换成一个完整的函数几乎不费吹灰之力，反正van Rossum建议将其作为 "多行lambda "方案的使用情况。
不用说，Python中多行lambdas的前景并不光明。
不太可能：一个没有 GIL 的 Python
全局解释器锁，或称 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。在这种情况下，提议的改变也将允许战略性地共享需要在子解释器之间共享的对象。
也许：一个Python本地的JIT编译器
在保持Python语言所喜爱的灵活性的同时，有一个行之有效的方法是使用一个即时编译器，或称JIT。JIT 编译包括在运行时分析代码，而不是提前分析，并根据它在运行时表现出来的行为有选择地或完全地编译成机器代码。
Python已经存在JIT。PyPy是最常用和发展最好的例子，它擅长在不修改程序源代码的情况下使长期运行的、服务器式的应用程序提供更好的性能。但是Python的参考版本CPython会不会从某种JIT中受益呢？
最近在2021年Python语言峰会上讨论的使Python更快的倡议，产生了一些类似的建议。目前的建议不是在Python中实现一个完整的JIT，而是在解释器中加入自适应行为，以便在常见的特殊情况下加快执行速度。未来可能还有其他类型的JIT类型的专业化的空间，比如为真正的高速代码路径生成机器码。但近期的计划是进行改进，扩展现有的解释器，而不是取代它。
