喜闻乐见的去掉 GIL 的两篇文章

[est]

https://lwn.net/Articles/754577/

https://lwn.net/Articles/754162/

[kslr]

啊，这糟糕的 python 我已经自废右手换仿生 nodejs 了

[jimages]

所以就是雷声大雨点小。

[jimages]

想要去掉 GIL 而做到向下兼容是不可能的，只有再等 python4 了........

[Cbdy]

@jimages 搞不好 py4 又和 py3 不兼容，这就完彻了

[pathbox]

想去 没搞个大动静很难吧

[est]

@kslr nodejs 压根就不支持原生线程。GIL 也就无从谈起。
@Cbdy 文章里有写。python 3.8 计划搞一搞。2018 年 8 月发版。

[blackjar]

那么多解释器 换一个用啊 或者大佬自己写一个好了

[copie]

@jimages 不是说 Python 这门语言是不需要 GIL 的吗？
GIL 是 Python 解释器实现的锅，自认为没有兼容性问题。个人推测

[est]

@copie Python 标准里的确没有规定必须用 GIL。CPython 的 GIL 是绕不过去的。 然而大多数生态都是围绕 CPython 的。所以然并卵。除非你用纯 Py 不依赖任何第三方库。

[neoblackcap]

@est 其实按 GraalVM 的思路是可以的，Python 实际运行的是 GraalVM 的字节码，至于 C 扩展，编译成 LLVM IR，也是又 GraalVM 运行，这样就可以做到底层的都是字节码，而上层不变。

[est]

@neoblackcap 好像没那么简单。很多 C 扩展依赖特定的 ref counting 内存 allocate 机制。比如 numpy。

[neoblackcap]

@est 依赖特定实现的行为都是异端，哎~，这样的没法说。

[blless]

pypy 不是有一个无 GIL 版本？

[blless]

http://doc.pypy.org/en/latest/stm.html#what-pypy-stm-is-for

[RqPS6rhmP3Nyn3Tm]

一个古老的笑话
python 是一个双管猎枪，但是一次只能发射一颗子弹

[orangeade]

@kslr js 语法不更糟糕，还有弱类型，
性能这一块确实不行，毕竟没有大金主

[kslr]

@orangeade 那也比 python 半死不活的好

[qsnow6]

有协程就行了 GIL 没有去的必要

[Arnie97]

@orangeade 现在有编译到 JS 的语言试图弥补一部分坑，例如 TypeScript

[PythonAnswer]

还不如多花点精力提高解释器在其他方面的速度