GIL 是什么？GIL 的全称是 Global Interpreter Lock（全局解释器锁），它不是 Python 独有的，而是在实现 CPython（Python 解释器）时引入的一个概念。我们可以将 GIL 理解为一个互斥锁，用来保护 Python 里的对象，防止同一时刻多个线程执行 Python 的字节码，从而确保线程安全。
然而，GIL 存在一个弊端，即在同一时刻只能有一个线程在一个 CPU 上执行，无法将多个线程映射到多个 CPU 上，使得 Python 并不能实现真正的多线程并发，从而降低了执行效率。
现在，Python 团队已经正式接受了删除 GIL 的这个提议，并将其设置为可选模式，可谓是利好广大开发者。
做出这一贡献的是一位来自 Meta 的名叫 Sam Gross 的软件工程师，他花费了四年多的时间才完成这一工程。
在得知这一消息后，大家纷纷叫好，深度学习三巨头之一的 Yann LeCun 发文祝贺：没有了 GIL，现在，Python 代码可以自由的执行多线程了。
「Python 中终于没有 GIL 了！」
「这是一个里程碑式的决定，是编码社区所热切期待的。」
具体细节如何，我们接着看下文。
CPython 核心开发者 Thomas Wouters 撰文描述了 Python 中的无 GIL 细节，并对未来发展做了展望。
非常感谢所有人对无 GIL 提议的反馈，整体上都持积极的支持态度。指导委员会打算接受无 GIL 提议，并就以下具体细节与大家分享。
我们的基本设想是：
- 长期来看（大约 5 年以上），no-GIL 构建应是唯一的构建；
- 我们希望非常谨慎地向后兼容。我们不希望出现另一个 Python 3 的情况，所有适应 no-GIL 构建所需的任何第三方代码更改应只适用于 with-GIL 构建（尽管仍要解决更老 Python 版本的向后兼容性问题）。这不适用于 Python 4。我们仍在考虑对这两个构建的 ABI 兼容性和其他细节的要求，以及对向后兼容性的影响；
- 在我们承诺完全转向 no-GIL 之前，需要看到社区的支持。我们不能只是更改默认设置，更希望社区弄清自己需要做什么工作来给予支持。我们核心开发团队需要获得新构建模式及相关所有内容的经验。我们要整理现有代码中的线程安全性，因而需要弄明白新的 C API 和 Python API。我们在获得这些洞见时还需要传达给 Python 社区的其他人，并确保自身想要做出的更改以及希望他们做出的更改是可取的；
- 在我们默认 no-GIL 设置之前的任何时候，如果事实证明了，它的破坏性太大导致收益太少，我们希望能够改变主意。这也就意味着我们会回滚所有工作，因此在我们确定要将 no-GIL 设为默认方式之前，特定于 no-GIL 的代码在某种程度上应是可识别的。
目前，我们认为未来的道路分为以下三个阶段：
- 短期内，我们会将 no-GIL 构建作为一种实验性构建模式，大概是在 3.13 版本（也有可能推迟到 3.14 版本）。之所以是实验性的，是因为我们核心开发团队虽然支持这一构建模式，但不期望整个社区都会支持它。我们需要时间弄清自己要做什么，至少在 API 设计以及打包和分发方面，从而得到社区的支持。我们也不鼓励 distributor 将实验性 no-GIL 构建作为默认解释器发布。
- 中期来看，在我们确信得到足够的社区支持并使 no-GIL 的生产使用可行后，我们将支持 no-GIL 构建，但不是默认方式，而是在某个目标日期或某个 Python 版本中使它成为默认方式。具体的时间将取决于很多因素，比如 API 更改最终兼容性如何、社区认为他们仍然需要做多少工作等。我们预计这至少需要一至两年的时间。一旦我们宣布支持，预计将有一些 distributor 会开始默认发布 no-GIL。
- 长期来看，我们希望 no-GIL 成为默认方式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。我们不希望等待太长时间，毕竟两种常用的构建模式同时存在会给社区造成很大的负担（比如需要双倍测试资源和 debug 场景）。但是我们也不能急于求成。我们认为这一过程将需要花费五年的时间。
当然在整个过程中，我们整个开发团队将需要实时评估进程并对时间线进行调整。
