在退休又复出加入微软的 Faster CPython 团队后， Python 之父 Guido van Rossum 在 2021 年 Python 语言峰会上放下狠话，称团队将在 Python 3.11 版本中实现至少提速 1 倍的进展。
而在今年的 Python 语言峰会上，Guido 和团队搭档 Mark Shannon 汇报了最新的进展：对比 3.10 版本，CPython 3.11 的提速在 10 - 60%之间，具体速度取决于代码规模和工作领域等条件。 当使用 pyperformance 基准套件测量在 Ubuntu Linux 上使用 GCC 编译时， CPython 3.11 平均比 CPython 3.10 快 25% 。
CPython 3.11 的性能改进主要集中在更快的启动和更快的运行时，这些优化大部分来自于 PEP 659 ：自适应解释器，它运作思路跟 JIT 有点相似，都是识别热点代码，但自适应解释器的工作范围无法脱离字节码。目前 PEP 659 提案的工作基本完成，但 for 循环和二进制操作的动态优化仍有待完成。
在提速 25% 的同时，Python 3.11 仍有一些需要改善的地方，比如 Python 在 3.11 中的内存消耗与 3.10 中的基本相同。此外还需关注 C 扩展的问题：CPython 与 C 的简单接口是主要优势，而与 C 扩展的不兼容性则是一大槽点。而 Faster CPython 团队在 CPython 3.11 中所做的优化工作在很大程度上忽略了扩展模块的问题，对此，团队领导者 Shannon 表示，团队正在开辟将低级函数 API 暴露给虚拟机的可能性，以尽可能地减少 Python 代码和 C 代码。
至于饱受期待的 JIT 编译器，Shannon 表示实现 JIT 的第一步是实现一个跟踪解释器，但目前还有太多需要关注的项目，引入 JIT 编译器的工作还有一段路要走，“最早可能要到 3.13 才能到达”。(顺便说一下，Shannon 一直对 CPython 是否真的需要引入 JIT 持怀疑态度。)
有意思的是，昨天我们报道了开发者 Sam Gross 的新提案：完全移除 CPython 解释器的 GIL- 全局解释器锁 。这个提案和 Faster CPython 团队的工作将以截然不同的方式加速多线程 Python 代码，但两者又可能产生一些冲突，毕竟 Faster CPython 已实施的优化，很大一部分都基于 GIL 仍存在的前提。
以下是本文的参考资料相关链接，感兴趣的朋友可以前往了解 CPython 3.11 的优化细节，以及 Faster CPython 团队的具体工作：
论强、动态类型语言，Python 只要说：还有谁！！！一众 Script 就的退出聊天室（当然最痞的 JS 自然最后退出）
相对于C而言Java也是动态类型语言（所有对象都是 Object 实例），而C本身也有弱类型特性（比如 int、float 混合运算）
S不S山的也是相对的、因人而异的。
有些人（我）因为不喜欢S山而选择了Python，因为Java怎么写都是S（繁琐、冗长）。
而有些人，却因为不喜欢S山而选择了Java，因为他们写Java小S，写Python是大S。
我觉得应用层面开发，业务逻辑BUG更致命。
动态语言没有编译器检查，出问题程序抛出异常，数据该回滚的回滚了，顶多某个没测试到的小功能用不了而已。
静态语言虽然有编译器检查，但语法繁琐、冗长，更容易出业务逻辑的BUG（业务逻辑BUG引起的错误数据更可怕）。