当 Python 默认 No GIL 后， Web 框架是不是要大洗牌了

什么时候 nogil 会默认启用？

感觉并不会...框架都上用了，GIL 这点东西，影响不大

py4 之前都不可能默认 no gil

用 async 不就行了, 有啥区别

然后一个进程不够多开几个进程服务器就是

@iorilu #4 多进程就需要中间件共享通信了，尤其是 WebSocket 这块

@maocat Py No GIL 之后，数据之间通信怎么解决的？

No GIL 是啥？求您讲讲。

看了一下，感觉没啥大影响吧……

据说去掉 GIL 后，，python 编程会变复杂，使用难度会上升。。有多少人会接受这种代价？？

语言原生性能差, nogil 有啥用,本身就是走偏的路子

不会，FastAPI 等新框架火起来并不只是 async 支持的好，只用同步模式也比 django 这些老古董好用

No GIL 在很多方面不是提高性能，在不开启多线程情况下，比原来的 python 版本性能更差

web 很多时候是使用协程而不是线程 用用 async IO 的居多

No GIL 对单线程的场景有负面影响，预计很长一段时间都不会默认 No GIL 。
No GIL 对 Web 框架来说没有用，本来就会起多个 Worker 。

目前还没有默认 no gil 的时间，起码再等五年吧。

生态就这样了，没有多少人在纯 Python 里跑多线程 CPU 密集任务。

我记得你，魏斯理汉堡

@tingg 哈哈哈哈哈，那你吃了吗，真的好吃啊

@maocat #18 下次回西安就去吃

再快还能比 go 跟 rust 快？ 反正用 python 本身就不要太期望于高并发

@RangerWolf 虽然我同意你的观点 且认为 Python 的主场在 AI 而不在 Web 但是楼主想讨论的大概是 Python Web 而不是 Web 所以没必要跟其它语言对比 只讨论 Python 本身就好

No GIL 应该主要还是针对 AI 的场景，Web 那块感觉没什么动力去改。毕竟 No GIL 其实主要就是提高计算性能，Web 那块又不需要海量计算，可能瓶颈在 IO 更多一点。

@iorilu

gil 的问题是多线程的情况下，其实只有一个线程在工作，所以在有 gil 的情况下，多线程跟一个线程用 async 的性能一样。

如果没有 gil ，那么多线程的就跟有 gil 的多进程一样了，还不存在进程间数据共享的问题

@rogwan 线程之间的数据共享啊

我希望可以彻底解放 python 画界面的多线程限制，pyside 这玩意虽然好用，但是单线程让这玩意全和业务锁一个线程里了，io 任务耗时一长比亚迪的 ui 界面直接卡死

单人项目怎么爽怎么来。团队开发最好还是用静态类型且语法呆板的东西。Go 或者 Java 这种东西大行其道真有他的道理

GIL 是进程锁， 开销极大， 没啥用

落后太多了，安心做 ai 计算器吧

@xing7673 No GIL 之后，还是用 threading.Event()、Queue 、threading.Lock() 共享数据？

nogil 性能和内存占用还倒退了一部分，如果不专门做多线程优化的话，还是用 gil 的版本比较好

@twig #7
问了一下 ai
GIL (Global Interpreter Lock ，全局解释器锁) 是当前标准 Python (CPython) 解释器中的一个核心机制。你可以把它想象成一个“通行证”。

功能：在一个 Python 进程中，无论你有多少个线程，GIL 都确保同一时刻只有一个线程能够执行 Python 字节码。

目的：GIL 的主要目的是保护 Python 内部的数据结构，简化内存管理（特别是引用计数）。它使得编写 C 语言扩展变得更容易，因为扩展的开发者不必处理复杂的多线程同步问题。

简单比喻：
想象一个厨房里有多个厨师（线程），但只有一把菜刀（ GIL ）。无论有多少厨师，同一时间只有一位能用这把刀切菜（执行代码）。这对于需要等待烤箱预热（ I/O 操作）的厨师们来说没问题，但在所有人都需要切菜（ CPU 计算）时，效率就非常低了。

@rogwan #28 噢你想问的是范式上的解决方案啊，那现在还需要迭代，毕竟性能上才刚刚过及格水平

人得不, 因 Python 的吸引力就不是源自行速度, 所以如果某天 Python 被化不可能是因行速度太慢, 某天一天下也不是因行速度超越.

@RangerWolf 并发都是下层的..指不定下层是 rust 实现的..例如 py 框架 Robyn 是 rust 的运行时

不如用大 PHP ？

搞 WEB,多进程和多线程在并发不高的情况下,差距有多大呢?