执行模型变体——未来的可能性？ | 第一部分 开始 —— 第 2 章: python 是如何运行程序的 |《学习 python：强大的面向对象编程（第 5 版）》| python 技术论坛-江南app体育官方入口
最后，注意到这里简述的运行时执行模型其实只是 python 当前实现的人造产物（实现细节）而非语言本身。比如，一个完全的，传统的用于翻译 python 源码为机器码的编译器可能会在本书的流行期内出现（虽然事实上在过去二十年没有一本书有过这样的情况，所以这种可能似乎不太可能！）
新字节码格式和实现变体也可以在未来被采用。比如：
-
正在进行中的 parrot 项目旨在为各种编程语言（包括 python）提供一个通用的字节码，虚拟机和优化技术。python 自己的 pvm 运行 python 代码的效率要高于 parrot（如在一个软件会议上，被一个 pie 挑战展示得众所周知——在网上搜索来获取细节），但不清楚关于 python，parrot 会如何的演化。参见或整个网络获取细节。
-
之前的 unladen swallow 项目——一个被 google 工程师开发的开源项目——努力寻求让标准 python 变快至少 5 倍，且快到足以在许多情况下代替 c 语言。这是 cpython（特别是 python2.6）的一个优化分支，通过添加一个 jit 到标准 python，旨在兼容却更快。在我在 2012 年写下这些文字时，这个项目似乎已经快终结了（从它在 python pep 中被撤销（的情况）看，它即将死亡）。然而，它得到的经验教训可以以其他形式被利用起来；在网上搜索突破性进展。
虽然未来实现的方案可能在一定程度上更改 python 的运行时结构，但字节码编译器看起来很可能将在未来一段时间继续成为标准。字节码的可移植性和运行时灵活性是许多 python 系统的重要特性。而且，添加类型约束声明来支持静态编译很可能会破坏许多灵活性、简洁性、简单性和 python 编程的整体原则。由于 python 的高度动态特性，任何未来实现将很可能保留当前 pvm 的许多实现和设计（注：因为当前的 pvm 处理这种高度动态特性是如此优秀，如果随便修改，很可能还达不到现有效果）。
