以下是目前 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类型的专业化的空间，比如为真正的高速代码路径生成机器码。但近期的计划是对现有的解释器进行扩展，而不是取代它。
