推荐学习书目 Learn Python the Hard Way Python Sites PyPI - Python Package Index http://diveintopython.org/toc/index.html Pocoo 值得关注的项目 PyPy Celery Jinja2 Read the Docs gevent pyenv virtualenv Stackless Python Beautiful Soup 结巴中文分词 Green Unicorn Sentry Shovel Pyflakes pytest Python 编程 pep8 Checker Styles PEP 8 Google Python Style Guide Code Style from The Hitchhiker's Guide
Python 开始准备让 GIL 变为可选了(PEP 703)
huangzhe8263 onlyacat 2023-10-27 10:31:55 +08:00 3536 次点击这是一个创建于 784 天前的主题，其中的信息可能已经有所发展或是发生改变。
PEP 703 (Making the Global Interpreter Lock Optional in CPython) acceptance
Python 指导委员会宣布接受 PEP 703 （ Making the Global Interpreter Lock Optional ，让全局解释器锁成为可选），公布了实现 no-GIL （或称为自由线程） Python 详细的路线图。
CPython 的全局解释器锁（ GIL ）阻止了同时多线程执行代码，成为了在多核 CPU 上提高 Python 代码运行效率的一大障碍，消除这一障碍是好事，但这也有可能会破坏现有的扩展模块，或显著降低性能以及可维护性。
而第三方软件包生态系统是 Python 的一大优势，Python 项目在实现自由线程时需要谨慎，需要避免破坏这一优势。
推进 PEP 703 需要将其纳入主线，作为定期发布版本的一部分推出。Python 指导委员计划分成三个阶段：实验阶段，支持但不默认阶段，默认阶段。
 | 1 jjx 2023-10-27 10:34:56 +08:00 相当不以为然 放着 pypy 已经验证的 jit 可能显著的改变普通代码的性能不搞 搞这种东西 感觉决策的已经被绑架了 |
 | 2 proxytoworld 2023-10-27 10:40:11 +08:00 @jjx 为什么 pypy 应用范围不如 cpython |
| 3 jjx 2023-10-27 10:42:38 +08:00 |
 | 4 CEBBCAT 2023-10-27 10:54:48 +08:00 @jjx #1 我是 Python 菜鸟，社区也几乎不参与，不过我看到这个提案有一些讨论页面，推荐给你，也许现在提反对意见还不晚： https://peps.python.org/pep-0703/ https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606/9 https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075 https://medium.com/@karanpittie/pep-703-exploring-the-pros-and-cons-of-removing-the-global-interpreter-lock-gil-3b0d4e9d05e0 依次是： 提案 提案讨论 被接受后的讨论 Medium 社区总结 |
 | 5 Maerd 2023-10-27 11:03:16 +08:00 @jjx 不是那么好改的，pypy 的内存管理方式会影响 C 语言拓展的兼容性，pypy 的实现和 cpython 本身就是不同的，C 语言拓展通常需要直接操作 Python 解释器的内存结构，如果换为 pypy 的方式，那么绝大多数的 c 语言拓展都要挂掉。 |
| 6 jjx 2023-10-27 11:07:47 +08:00 @Maerd 肯定不是抄了代码, 是抄方案 pypy 对 c 扩展也有解决方案,就是 hpy, 只是 cpython 那些人不推动,就做不起来的, 例如这个 nogil pypy 已经有效的证明了 jit 可以改善普通 python 的代码从几倍到几十倍 实际开发这, 类似 xlwt/openpyxl/xhtml2pdf 这种纯 python 实现的, 能提速 n 倍 |
 | 7 o562dsRcFqYl375i 2023-10-27 12:02:05 +08:00 如果 Python 的原生性能问题能得到较好的解决，那 Python 真的挺无敌了 |
 | 8 sujin190 2023-10-27 12:09:58 +08:00 via Android @jjx 事实 pypy 毛病太多不流行是并不好用，内存消耗大非常多，预热很慢，扩展支持有问题，而且想自己编译十分麻烦，在生产环境用过很长时间，收益并没有想的那么高，还是又切会 cpython 了，十分友好的内存消耗和扩展支持才是 python 的优势，放弃了才是脑子有病，支持干掉 gil 但前提是不大范围提升内存要求和扩展支持要求，否则意义真不大 |
 | 10 makelove 2023-10-27 12:53:47 +08:00 原生性能这么差，上了这个多核也比不过 nodejs 单线程，且 nodejs 真单线程开发容易很多。业务要利用多核就用 worker thread |
 | 11 adoal 2023-10-27 12:59:26 +08:00 事实就是，对于社区驱动发展起来的草根语言，社区“官方”的“参考”实现是足够强势的，其它实现做得再好，有理念冲突的时候也掰不动“官方”的手腕 |
 | 12 bianhui 2023-10-27 13:24:19 +08:00 我觉得 no-GIL 对现有生态肯定是毁灭性的打击。之前很多项目，很多第三方软件包，得益于 GIL 的关系，开发的很简单。如果没了，很难想象切换，迁移的成本，最主要很多逻辑是隐藏的，不是说改就能改的。 |
 | 14 Huelse 2023-10-27 13:34:55 +08:00 要不直接改为 python4 吧，来个像当年一样的不兼容更改，或许会更好？ |
 | 17 wizardyhnr 2023-10-28 00:34:19 +08:00 CPython 的生态太香了，要么 CPython 上面缝缝补补，要重新另起炉灶重新构造生态，那还不如走 Mojo 路线纯追求性能。 非官方实现吸引不了开发者是不够香，怪官方也没什么意义吧，开发者都是用脚投票的。 |
 | 18 junkun 2023-10-29 01:24:32 +08:00 @duojiao 我也觉得估计又要搞一次 2~3 了。这个 no gil 基本就是为了满足 pytorch 用户想多线程加载数据的。说实话，就性能而言，gil 真不如 jit 重要。 |
 | 19 TryBetterApp 2023-10-31 15:25:49 +08:00 我对 no-GIL 也不感冒，Python 生态 & 基础设施库， 已经非常庞大了，做这个伤筋动骨的事，风险大于收益。（兼容性 & 测试成本 & 对齐成本） Mojo 已经在路上，可能未来需要 no-GIL 的场景，切 Mojo 就可以（ 100% 兼容保证）。 不在意 GIL 的场景，写 Python 依然是最舒服的。 （不乐观瞎猜，这个计划会随着 Mojo 的持续发展而流产，失去存在必要） |
| 20 Maerd 2023-11-02 09:24:27 +08:00 @TryBetterApp mojo 所谓的 100%兼容就是遇到 python 代码时在 mojo 里开一个 cpython 解释器，纯属脱裤子放屁的操作 |
| 21 TryBetterApp 2023-12-01 22:16:31 +08:00 |
| 22 Maerd 2023-12-20 11:31:50 +08:00 @TryBetterApp 实现解释器？很难想象他自己实现的 python 解释器如何兼容 c 拓展，即使是 cpython 都不能保证跨版本兼容，很明显只是个“兼容 python 语法”的新语言，和 python 比起来还差很远 |
Select Language