这里有四种常用的语言特性，目前Python中没有。他们中至少有两个人永远不会在那里，而其他人最多几年之后。我们将看看是什么阻碍了这些特性，或者需要做些什么才能将它们包含在未来的Python版本中。不会是：静态类型的编译Python一些开发人员梦想有一个静态类型的Python，它可以编译为本机机器代码。毕竟，灵活的类型让Python变慢，而静态类型将终结它。静态类型还为程序员提供了强有力的保证，使他们能够从代码中得到他们想要的东西。所以有什么问题？虽然Python确实有类型提示，但它们的目的是通过编辑时的提示功能使语言更适合静态分析。只有第三方项目（例如pydantic）在运行时使用类型提示。Python运行时本身不使用类型提示。在PEP484中，Python类型提示的增强建议中，有一个明确的目标是使类型提示永远可选。“Python仍将是一种动态类型的语言，作者不希望强制使用类型提示，即使是按照惯例也是如此。”真正想要静态类型版本的Python的开发人员可以求助于Cython或mypyc，但即使是这些项目也是有代价的。在Cython中，最大的性能提升来自使用纯C类型和结构，以及减少Python运行时的使用。简而言之，很难在不牺牲Python的活力的情况下使Python编译得更快。分离出不需要动态的部分并使它们更快会容易得多。否：多行lambdasPython的lambda表达式或匿名函数是有限的。它们只允许一个表达式（本质上，赋值中=号右边的任何东西）作为函数体。从以多行匿名函数为常态的JavaScript等语言转向Python的开发人员经常要求在Python中实现此功能。Python的创建者GuidovanRossum很久以前就驳斥了lambda不是单个表达式的语法糖的想法。他的立场在2006年的一封电子邮件中得到了最好的概述，他在邮件中讨论了为什么多行lambda没有也不会成为Python中的一件事。多行lambda几乎没有为Python增加真正的力量或表现力，并且以使其成为一种可读性较差的语言为代价。（可读性是Python最关心的问题）。目前没有可用的语法可以优雅地与Python的其余空白敏感设计集成。将多行lambda转换为完整函数几乎毫不费力，无论如何vanRossum建议将其作为“多行lambda”场景的用例。不用说，Python中多行lambda的前途并不光明。Unlikely:APythonGlobalInterpreterLockwithouttheGIL，简称GIL，长期以来一直是Python爱好者的眼中钉。GIL同步Python运行时内的活动以序列化对对象的访问并管理全局状态。GIL的缺点是它使Python运行时实际上是单线程的。如果你想要真正的线程并行，你需要启动Python解释器的不连续副本，并在每个副本上运行单独的线程。理论上，没有GIL的Python可以允许更大的并行性，从而提高性能。那么为什么不太可能呢？已经有各种建议从Python中删除GIL。大多数建议会破坏向后兼容性，或使Python在单线程操作中变慢，或两者兼而有之。其中一项努力，即“GILectomy”项目，带来了严重的性能损失。GIL在Python3.x中进行了重新设计以提高其基准性能，但为了保持向后兼容性而未将其删除。由于这些问题，GIL可能只是Python用户生活中的一个事实。但是可以提高它的性能。在Python运行时允许更好的并行性的一种方法是在一个进程中运行多个解释器。使这个提议成为现实需要对Python的内部结构进行重大更改，包括重做Python的CAPI的一部分。许多第3方模块依赖于CAPI，因此也需要更新。较新的提案PEP684扩展了多个解释器的概念，让每个子解释器都使用自己的GIL。在这种情况下，提议的更改还将允许战略性地共享需要在子解释器之间共享的对象。也许会有：Python原生JIT编译器在保持Python语言独特的灵活性的同时，有一种有效的方法可以使用即时编译器或JIT。JIT编译涉及在运行时分析代码，而不是提前分析代码，并根据代码在运行时的行为有选择地或完全地将其编译成机器代码。Python的JIT已经存在。最常用和开发最好的例子是PyPy，它擅长使长时间运行的服务器式应用程序在不修改程序源代码的情况下提供更好的性能。但是，Python的参考版本CPython不会从某种JIT中受益吗？最近在2021年Python语言峰会上讨论的使Python更快的倡议产生了一些类似的建议。目前的提议不是在Python中实现完整的JIT，而是在解释器中加入自适应行为以加快常见特殊情况下的执行速度。未来可能会有其他类型的JIT类型的专业化的空间，例如为真正高速的代码路径生成机器代码。但近期计划是扩展现有的解释器，而不是替换它。
