我从今年 PyCon US 2023 的几个 talk 角度说说 Python 在未来几年的发展方向。
未来5-10年目标，一句话总结：性能，性能，还是 tmd 性能。
过去有很多 Python 的不同实现，pypy、Jython、ironpython，结果他们都凉了或者快凉了，事实说明，在语言标准上不跟着 cpython 走，就是死路一条。做在 cpython 内部的一些编译器如 numba、taichi 之类的是靠谱的路径。
Python 之父 Guido 加入微软，领导 faster-cpython 项目，执行香农计划（Project Shannon，2020年由Python核心开发者 Mark Shannon 提出 cpython 性能提升计划），22年提出目标，就是未来5年，让 cpython 快5倍。
我个人也非常关心性能方面的工作，因为现在 AI 的发展非常迅猛，Python 作为其中主要的语言，性能提升对 AI 的发展有巨大的帮助。
2023 年 PyCon US，faster-cpython 组也做了几个演讲，介绍了 python 3.11 在性能方面的工作，并剧透了 3.12 (2023年发布）和后面的工作。
减少内存占用
从 3.2 到将来的版本，能减少 75% 的 object 内存占用，CPU 访问内存的次数也大幅减少（对于 CPU 来说访问内存是明显的开销）。
加速Python解释器
我们知道 Python 解释器之所以叫解释器，是它的主要作用就是解释和执行 Python 代码生成的字节码。加速方式主要通过引入专用的、自适应解释器。
dis.dis 显示代码的字节码
什么叫专用的？比如加法，以前就生成 BINARY_OP，这个对 float + float，int + int 甚至 int + float 都适用。这就是动态语言的特性嘛，但是每次都要检查类型什么的非常耗时间。通过引入 BINARY_OP_ADD_FLOAT 这种字节码，只用来做 float + float，就快多了。
什么叫自适应？就是一开始 Python 解释器对于加法，还是生成 BINARY_OP，当跑几个循环发现，你小子就是做 float + float 啊，那得嘞，我直接给你生成 BINARY_OP_ADD_FLOAT 来做 float 加法来加速。听上去怎么好像 JIT 呢？没错，未来的 CPython 会引入 JIT，但这不是一蹴而就的，CPython 必须考虑兼容问题，所以是逐步演进的。
通过对 Python 解释器引入 JIT 类似的技术，可以想象 Python 的性能能得到逐步提高。
子解释器
最后还有一个我个人关心的改进。作者 Eric Snow 在 2017 年就提出了 PEP 554，也就是在标准库里引入子解释器。
先说 Python 臭名昭著的 GIL 问题。不懂的看我的回答：
为什么 Python 的 GIL 问题一直让人诟病，Python 社区却不解决？简单来说，就是 Python 解释器里有个全局锁，导致多线程的CPU密集的任务无法利用多核计算。我的回答里也说要想移除 GIL 是非常困难的。中间可能的方案就是这个子解释器，因为每个子解释器有全局锁，但如果同时有多个子解释器，那么他们就可以利用多核，且创建子解释器的代价是相当小的。
作者在 POC了好几年后，终于有了进展，当时他说的时候几乎哽咽了，能想象其中的艰辛。
作者最后说到子解释器特别适合 Actor 模型，这就要安利我们的 Python 上的 actor 模型框架：
https://github.com/xprobe-inc/xoscar后续等这个特性可用的时候，我们会尝试将 actor pool （之前用一个进程），用线程+子解释器实现。这样再不需要用多进程了。
资料：
Talks - Mark Shannon: How we are making CPython faster. Past, present and future.：https://www.youtube.com/watch?v=wyty6sFMWI0&t=1219s
Talks - Brandt Bucher: Inside CPython 3.11's new specializing, adaptive interpreter： https://www.youtube.com/watch?v=shQtrn1v7sQ&t=1s
Talks - Eric Snow: A Per-Interpreter GIL: Concurrency and Parallelism with Subinterpreters： https://www.youtube.com/watch?v=3ywZjnjeAO4&t=1504s |
