[可能引战] 用过 Python 也没法理解为什么 Python 是个好语言

[noli]

看完标题请先冷静。

Python 除了标准库功能多来源繁杂，好像并没有什么可取之处。
毕竟真实项目中也不太可能只用标准库解决问题。

GIL 简直反进化
静态类型但是变量类型是可以重新绑定的……

求一个我没有想到的 Python 的优点

[Wincer]

Python 除了标准库之外，优秀的第三方库也不少吧？ numpy，ss
GIL 是 Python 实现的锅，并不是所有的 Python 实现都是带有 GIL 的
还有 Python 静态类型是什么鬼？楼主分不清静态类型和动态类型，弱类型和强类型语言的区别吗

[Vegetable]

你这个不会引战,大家只会单方面反驳你.
python 当然有很多缺点,除了世界上最好的语言,每一个语言都有自己的缺点.
也很少有哪个语言有独一无二的优点,所以都是整合起来看的.

比如 python 入门更简单,适用范围广,开发速度快等等这些优点,可能不是他独有的,但是偏偏做到了恰到好处.

[Mohanson]

场景不同，用不同的语言。你要硬拿他写 curd, py 是真的垃圾。但你要拿他写 demo，验证算法，验证工程可行性, 能节约你无数的时间。

https://v2ex.com/t/520987#reply23

我曾花了 10 天左右用 pure python, 且没用任何第三方库，甚至标准库都没怎么用，裸写了一个 webassembly 虚拟机，见上面的帖子。

[lihongjie0209]

脚本语言而已, 别太神化

[pythonee]

同感

[niubee1]

没理解到优点可能因为卤煮不大聪明， 呵呵， 开玩笑的， 因为都说聪明的程序员会选择 Python， 不是工作语言也会是排第二的辅助语言

[Jirajine]

说真的 Python 设计真的挺优雅的。要是有个编译器，效率高些就更好了。

[niubee1]

@Jirajine 有编译器， 自己编译自己，Pypy

[jeffersonpig]

你不需要去理解为什么别人觉得它是个好语言，你关注它对你而言是不是好语言就好。你是在为你自己的需要而使用，不是为别人。

[Sylv]

我想说：真香。

[Cooky]

没有大公司后台坐镇的通用型语言能活成这样很难得了

[impl]

95 年的语言，现在还这么流行，已经很牛逼了。看看同是脚本语言的 perl，ruby 都歇菜了。。

[impl]

95 年 -> 91 年

[littlewing]

弱类型是最恶心的

[clino]

觉得不好就不用咯

我的看法是 python 的开发效率高，写起来舒服，足够成为我选择的理由了。如果要抠效率的场合就不合适了。

[la2la]

@Vegetable 真的只是入门简单，写比较优雅的 python 开发，感觉比 java 还要难啊。尤其是多人开发，没有啥规范的时候 o(╯□╰)o

[kxiaong]

喷 GIL 不会引战，python 在 GIL 问题上就是反进化的。最该喷的是，都 9012 年了，社区还不努力解决这个问题。

喷弱类型的，可能还是有点偏颇。 如果认为类型标注是个特别重要的问题， 那就应该换别的语言。python 的弱类型在它该适用的场景就是很好的优势，在不适用的场景就是弊端。 怕出问题就该好好规范代码，而不是喷语言本身。多牛逼的语言都架不住码农乱写。

在没有大厂背书的情况下，纯社区力量把 python 推进到现状， 换任何一个别的语言都不行。

别把语言当作自己的瓶颈和局限。 在合适的地方用合适的技术就好。 看不惯 GIL 就自己去优化， 搞不定就换别的语言。 喷不解决问题本身。

[fy]

理由举了好几条，但是唯独最重要的东西没说：
好用吗？方便吗？

好用就用 不好用就不用

[FrankHB]

@Wincer
既然知道 GIL 是具体实现为主的锅了，也请注意 numpy 的可用性长期依赖具体的实现而不是 Python 语言。
虽然 LZ 少根筋，也别把弱类型这种民科概念堂皇地提出来。

[xrlin]

静态类型和动态类型都分不开。。。python 第三方库质量挺高的，django flask numpy 之类的，文档也齐全，gil 和效率确实是个问题，性能要求高的不是 python 的使用场景。

[oblivious]

Python 的一个优点就是：极大的简化了不需要开发项目的研究人员编程的学习曲线。

以前的科研人员：设计一个算法，Pascal，C 实现，然后另外的科研人员花一周时间学会如何调用，如何修改代码换一个小小的功能。

现在的科研人员：花 6h 时间直接学会 py 所有基础功能，然后可以开心的魔改各种别人的代码了。

[Takamine]

没有大括号，一个标尺解决问题的语言还不够好吗。:doge:

[janxin]

@kxiaong 不不不，2019 年了，应该会在明年绕开 GIL （支持多虚拟机在单进程中运行

具体请参考：
peps/pep-0554/
pythoncapi.readthedocs.io/runtime.html

作为纯社区支持，确实已经很不容易了，看看隔壁 pypy 那可怜的...

[ch3nOr]

@littlewing
但是 Python 是强类型的啊

[FrankHB]

@Takamine 一样得被 PEP-8 教做人。

[Osk]

python 不是动态强类型吗？？？

[noli]

@Wincer #1

莫要激动，一时笔误打错了，是强类型和动态类型。
numpy 其他很多语言也有替代品啊，虽然可能不太为科学界所知悉。
numpy 运算效率很搞吗，浮点运算能力能搞得过显卡吗？


@Vegetable #2

容易让新手入门是个好的优点，是 python 的哪个特性让它易于入门呢？
至于开发速度快这个，恐怕也是见仁见智，因项目不同的吧？

@Mohanson #3

我也写过寄存器式虚拟机。最难解决的问题是执行效率。
用 python 写有什么优势吗？

[secondwtq]

@noli numpy 是一个软件，GPU 是一种硬件，你既然写过虚拟机应该知道这俩是没法拿来比的

我的理解一般把 Python 当成“好语言”的人，并不会对自己所使用的语言特别认真，也就是说换成 PHP 他们也会说“好语言”，此类群体一般会持类似“能解决问题的语言就是好语言”“语言最重要的是生态和背后的爹”之类观点

之所以现在吹 Python 的比吹 PHP、Ruby 之类的多，因为 Python 的适用范围比 PHP 广，智商兼容性比 Ruby 高

[Vegetable]

@noli #27

作为动态类型,没有类型声明,代码精炼,语义化更好,更接近伪代码,实际上就是更接近自然语言.
关键字比如关系运算采用 and or not 而不是&&||!这种符号也更容易理解.
多范式支持,初学者不需要学会定义函数,就可以完成一些简单的工作.学习过程更平滑.
环境简单,傻瓜式安装,不需要配置,新手可以下载安装包就可以直接从交互式环境开始.

开发速度快就是快吧,我觉得没什么可讨论的,在脚本语言里肯定不是最优秀的,leetcode 感受比较深,只有 python 是最适合刷题目的.更能专注于问题本身,其他的语言哪怕再熟练也不得不多写很多字.

[mywaiting]

除了 GIL，以及 GIL 导致的性能低下问题，我觉得 Python 没有太多可以喷的地方

什么动态类型、什么限制缩进，感觉这些都没有喷对地方，难道你写其他语言不缩进？

要说 Python 最大的好处，就是这语言几乎不限制你的表达，怎么喜欢怎么来

[FrankHB]

@noli 大部分情况下打得过 Fortran 就够用了，不用考虑硬件问题。

关于 Python 容易入门的说法好像从来就没看到有正式的 PL 研究提过，所以可能只是大众迷因，和“ PHP 是最好的语言”类似。

实际具体点的原因大概是，和 C++之类的比起来，Python 看起来似乎是没那么坑，不需要之前有其它语言的丰富经验，于是“被简单”了。如果这些用户已经足够了解了其它语言，可能就不会有这样的想法。对不以 Python 也不以比 Python 明显复杂的语言作为入门的用户来讲，看样子也普遍不觉得 Python 简单。

Quora 上有人问“ Is Python an easy language to learn ”，下面有回答总结了不少，但其实多数是其它高级的动态语言也具备的。唯独“ designed to be English like ”，我看来是寅吃卯粮，因为实际上并不 English-like （真刻意 English-like 的设计都挺烂的，因为说实话 English 拿来应付表达算法之类的目的就不咋地……），这是把理解的复杂度扔给之后倒腾了。

还有就是 @secondwtq 暗示的从众。不过其实细讲起来 Python 并没有个好爹（ GvR 设计水平不咋地而且作为 dictator 都搞砸了不少事情），而且流行起来也相当偶然了。

[charlie21]

某某语言 是给那些驾驭不了 xxxx 的人用的，比如 科研人员、数据科学家

修玩具四驱车就用四驱车工具箱就可以了。你拜的是三一重工、三菱重工，他拜的是奥迪双钻

python 奥迪双钻 你的伙伴

你不能指望拿一个四驱车工具箱去修理南京长江大桥吧

-

[charlie21]

也不是说 python 不好
玩玩可以，别耽误了正途 ( C++, C, Java, C# ) 。你一个高级工程师 业余爱好喜欢玩四驱车 也可以。但你不能说 你就是一个专业玩四驱车的，你就是高级工程师了

[liprais]

面向对象一坨屎，缩进是语法的一部分，还有那精神分裂的 api 设计，更别提那包分发机制，这语言哪里好了.....

[FrankHB]

@mywaiting 你觉得是你觉得，不表示别人觉得的就没问题了。

所谓的动态类型我不喷（反过来我还要喷所谓的“静态”本身，或者强调“静态”的 Robert Harper 流的扯蛋）所以略过。

限制缩进首先是对用户选择的冒犯。用户会缩进不表示语言设计者替用户选择就是道德上正当的，撑死这也就是一部分人的选择。加上 free form 和决定如何缩进一贯是历史传统上的用户权利，突然就收归 GvR 之流所有了？敢限制自然就得准备好被喷。

更进一步地，如 PEP-8 这样钦定缩进用空格的，我可以认为是分不清缩进和对齐程度的反智。（不过这是另一回事了——缩进用不用空格的显然不是 Python 独家问题。）

其次，限制缩进是对语言理论（形式系统意义上的“理论”，反映到工程上主要是语言 spec 的表现形式）的简单性的破坏。限制缩进的规则导致 parse 时就很难卸掉一个单独的 phase，而必须导致抽象泄漏；这也导致扩展 spec 派生其它语言的一些困难而损失语言 spec 的可用性。（说远点，钦定 phase 是我喷“静态”的根本理由，只不过这个和 Python 也没直接关系就是了。）

然后我给你追加一个 GvR 本身的反智（先不提这人搞 PL 设计的意义上不务正业很久了，什么 lambda 该限制几行的破事也瞎倒腾……）：连 proper tail recursion 和 tail call optimization 也分不清，不懂 shadow stack 还会借口阻碍 debug 瞎限制 stack depth，被人教育后还是“和尚念经老子不听”，这种水平的爹的语言敢通用？

关于这个 feature 设计大方向的“工程影响”问题，一个 lua 就够打脸咣咣响了。（虽然有违反 EWD 831 的另一个反智问题，也是屑。）

这些问题你都当“不限制你表达”的话，也是醉了。

[youngxu]

至少对科研人员来讲很友好，简单易上手。就拿计算物理课程说，前几届学长用的是 fortran，但我们这一届换成了 python，（人的）效率提升不是一点半点

[sazima]

写过 python 写过 java, 最后还是选择了 python 的简洁

[charlie21]

什么编程语言选择，哪这么多内心戏？

这其实不是你的选择，是甲方的选择。甲方指明了 不让用 python，让用 java，那么你就得用阿 —— 要不你就别干了

至于甲方为什么选择 java 而没选 python，这不是显而易见的么？
人家志在修建南京长江大桥，自然不想拿四驱车工具箱凑合

-

[VinsonGuo]

已经被 java 的 ide 惯坏了，想问下 py 大佬们 ide 经常不提示是怎么解决的，难道那么多 api 都能记下来？

[charlie21]

( 当然，在另一群人的眼里，他们修氪星β域长江大桥，他们眼里 java 才是四驱车工具箱，python 才是正经工具，
他们也是修桥的 -- 玩具桥也是桥、氪星β域长江大桥 也是 桥 -- 所以他们不想拿四驱车工具箱凑合，所以 选择了 python ) 滑稽

氪星人的眼里的四驱车工具箱和你眼里的四驱车工具箱是不一样的

他人觉得 python 是正经工具，你觉得 java 才是正经工具；这里的互相否定，是很正常的，不是否定对方的工具，而是否定对方干的活儿：
在氪星人眼里 氪星人看地球人的南京长江大桥是玩具 那么让地球人用 java 这种玩具语言桥修他们的玩具桥 是很自然的；
在氪星人眼里 氪星β域长江大桥 才是需要正经对待的，自然要用 python

所以 问题来了：你是地球人还是氪星人

[mywaiting]

@FrankHB #35 既然 at 了就得回复吧

缩进这事情，虽然 pep8 要求用空格，我习惯用 tab，没啥问题。不过强制缩进，个人认为不强制也会按照语句逻辑来缩进，这个有好争论的

至于说缩进会导致理论上的破坏，我不懂太多高级编程语言理论，当我小白不懂吧

至于扯到 lambda 和 尾递归优化，我觉得这也是 python 在这些主流的语言稍微能有支持函数式编程的特性了，我的观点是基本能用。不是 lisp 出来的，我觉得不必求全责备吧，这个都能喷，除了 js 我觉得其他一票的语言都能喷出渣了

Python 中这个 stack depth 的问题，我没有研究过，不过 shadow stack 并非灵丹妙药，栈安全这问题不容易解决

限于水平，目前我确实还没有太多能限制表达方面的发现

[qcts33]

@noli numpy 的可以认为是 BLAS 等计算库的一个包装，确实其他语言也可以去包装一下 BLAS，甚至有的语言本身就支持矩阵运算(Julia MatLab R)，但基于 numpy 所建立起的生态是其他语言所不具备的(scipy sklearn pandas)。
要说在科研领域要替代 python 的语言也有。
MatLab 是老牌的语言，但由于是商业软件，我觉得没有太多的可比性。
R 也是老牌的语言，而且在统计领域的应用非常广泛，但由于其语法设计比较别扭，其市场也在被 python 蚕食。
Julia 作为一个后起之秀已经作出了很多努力，写法上学习 MatLab 比较多，支持 JIT，可选静态类型，可以说是解决了 python 的很多问题。但其生态还是很成问题，实际应用比较有限。

至于 numpy 的速度，得益于 BLAS，其速度基本可以发挥 CPU 的最大潜力了。而要说 GPU，python 的包中也不乏对 GPU 的包装，常见的包括 Tensorflow 和 pytorch。另外我推荐一下 jax 和 cupy 这两个不是很出名的包，其最大的特点就是与 numpy 的 api 向兼容。

[FreeEx]

@VinsonGuo 所以写 py 需要双屏，一个看文档，一个写代码，没文档是写不了 py 的。

[gsj987]

我是习惯遇到需求先写个 python 脚本，用简单的数据或者场景模拟一下，然后直接并入 django 写的系统提供对外服务。非常简单。

当然作为写了十年 python 的程序员，我也不得不说 python 在很多方面有他的缺点，别的不说，就说这个语法吧，代码一多就一坨一坨的，没啥优美性可言。

[exceloo]

脚本语言，即时上手，在服务器上只要环境搭好，想开一个小脚本，随写随用，主要是方便吧。

[Yourshell]

可是跟其它语言比起来也没那么差不是？

[FrankHB]

@mywaiting

我同意缩进在逻辑上更清楚，但这本质应该是 AST 层次上的结构化的表示；这和文本的、书面的、可打印的代码并不一定是一一对应的。否则，对齐也是毫无意义的了。

缩进检查的理论问题倒的确不是那么了然，不过副作用有个简单的表现：IndentationError 到底算是 syntactic error 还是 semantic error ？照一般的习惯，里外不是人。

Lambda 和 TCO 的问题是指出作为爹的 GvR 关于这些（工程上）简单的问题自己没干好活也没引导社区。

至于缺少 PTR/PTC 之类的保证作为缺陷，C/C++在更一般的情况下显然还更糟糕，stack overrun 直接 UB，而且一般实现多大会炸原则上不可预测，导致严格意义上就没多少程序能保证语言层面上可移植的。这不照用么……
Python 的基本做法是保证不会炸得莫名其妙，这起码是工程上更正确一些的。
Shadow stack 这里是解决可调试性问题（保留 stack trace ），对安全没有影响。Stack inspection 原则上也是兼容 PTC 的[1]。

缺少 PTC 导致一些程序（如 [2] Part III，某些 CPS 程序，某些依赖互递归的自动机）的直接实现无法被准确简单的表达，其变通就是人肉翻译成更底层（更类似机器语言口味）的代码。对高级语言用户来讲，这就是显然的不友好的限制。

[1] www2.ccs.neu.edu/racket/pubs/cf-toplas04.pdf
[2] www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf

[anonymous256]

“真实项目中也不太可能只用标准库解决问题”，不同意的。

说说我在项目中用到的标准库，ftplib(一个 FTP 库)，json，pathlib(路径处理，谁用谁知道。其它语言一个能打的都没有)，collection(高级数据结构)，typing(类型注释)…

第三库也用了一堆，省去了重复造轮子的时间，一句 pip install 就能搞定，太省事了。

使用的方法优雅。实例化一个对象，调用下方法就解决问题了。

楼上说代码一坨一坨的，那个应该是自己代码的问题了。我以前也那样，现在写的函数大多很短。一个功能就一个函数，该拆分就拆分。和语言无关

[necomancer]

@oblivious 作为科研党必须给个赞

[akira]

引用我以前常对人说的 如果你觉得 xxxx 没什么用，那说明你没有这个需求

个人觉得 py 更适合非专业开发人员使用，例如 科研人员 /数学研究工作者 /教学工作者 /运维人员 等等

或许你是习惯了用锤子，但是 py 是个扳手，那不能用锤子的标准来衡量扳手啊

[necomancer]

@noli 作为非数学科研人员，非数学方面高浮点计算力需求除了很多已经有人做好的开源 /商业实现(lammps, gromacs, gauss, amber, MS...)，现在基本上是用 NumPy 了，而很多成名已久的老软件也开始 C++/C, CUDA 然后用 Python 做胶水这样，numpy array 作为“苦力”，这样在程序运行中很方便实时自己写东西进行处理。NumPy 的各种操作基于 MKL，效率还是很高的。我所知道的纯数学类用得比较多的可能是 Matlab 和 Mathematica，但可能是符号运算、各种群论图论拓扑之类的神仙操作比较多吧，干暴力浮点运算要求少，他们的神仙课题不太懂。至于 CUDA，如果不是要使劲搞一个 lammps，gromacs 体量的大作，numba 的 jit, vectorize, cuda.jit 和 cython 基本上非常够用。从好上手的角度上说，Python 确实最友好，各种格式的读写，和 C, Fortran （没错，科研党还有相当一大部分人用） 的接口全面，NumPy 的向量化操作也让代码很具有公式上的可读性，而且非数学并且有大量暴力浮点运算的专业而言，Python 的入门要比 Matlab, mathematica 之类的简单得多，至于 Julia，生态算硬伤。

[tairan2006]

最大的作用是快速实现原型

[ps1aniuge]

这里贴 py 代码方便吗？

[txy3000]

没有完美的语言 只有合适的语言
选对了事半功倍 选错了来 V2EX 吐槽 🐶

[est]

拿 GIL 说事的，贴一下你们服务器监控，究竟多少核心有多少个并行任务？

2 CPU 那种垃圾云主机或者 docker 镜像洗洗睡吧。还轮不到 GIL 成为瓶颈。

[russian]

我最早写 c++，后来写 python, java, javascript。

感觉 python 和 JavaScript 差不多，然后他们都比 c++和 Java 效率高很多，就算是在商业软件开发的层面。c++的熟练工或者 Java 的熟练工绝壁不可能写的比 python 熟练工的速度快。

速度就是金钱。

[noli]

@est #55

我司产品所有的锁，都是改过的，都不会让系统线程进入等待。
请问够资格吗？

[mumbler]

我现在需要用一个脚本完成某些任务，不用 python，你给推荐个其他没毛病的语言？

[est]

@noli 一个文件系统 io 就会等待了。

[noli]

@est #59

反正不是锁导致线程等待。IO 频率这么低，一个线程和内核交换数据就够了。
倒是 GIL 这种东西明显造成非 python 进程与 python 进程间数据交换瓶颈。

那些说 Python 开发快的，我估计都是业务量不大，连原型都跑不垮的穷鬼公司吧。

[VEEX6]

油管体验过吧，这一点就足够

[noli]

@mumbler Powershell 怎么样？

[jokerlee]

语言的本身设计的好坏和市场份额内什么直接的关系，时势造英雄，合适的时间出现在合适的位置上就成了。

[jokerlee]

这个世界上就没有所谓的好语言，只有合适的语言

[iwanghang]

俗话说 PHP 是最好的语言啊

[jokerlee]

说一个 python 的优点吧，他是 linux 发行版里所有预装语言里最容易上手的，就算不会写大概率也看得懂。

[jim9606]

对于 python 小白入坑，可以很快就利用第三方库弄出个简单的 GUI 应用，还不用怎么理解计算机组成原理（非专业的一般学到这就可以拿去干活了），这是很有成就感的事，在这点上别的语言好像只有 js 能追上。

python 的代码功能直观。我相信大部分非 CS 专业的人学完 C++基础都不知道"using namespace std"是干啥的。

python 标准库冗余是为了兼容遗产代码，实际上很多东西已经不建议用了，也没必要特意去学，毕竟动不动就 break 兼容性对生态和产业影响都不小。(python2->3 已经折腾够久的了)

GIL 是 CPython 特有的，PyPy 就没这个问题，也是个历史遗留问题。

[plqws]

python 的标准库混乱，全局函数和面向对象混用，某些语法晦涩不明，依赖 /包管理稀烂，2->3 也是个问题。始终无法理解为什么能吹得神乎其神，什么 zen of python 更是大笑话

[fundebug]

python 的缩进简直变态

[est]

@noli 业务量大遇到 GIL，那肯定不是 IO 密集，而是计算密集。计算密集，就算没 GIL，py 那个小身板性能啥没法干啊。。。非 python 进程与 python 进程间数据交换你们用的 multiprocessing 之类的直接传递对象么？如果换成消息队列呢？

[est]

@jim9606 pypy 有 GIL 这个问题。

GIL 是支持内核线程的语言特有的问题。比如 nodejs 这类连原生线程都不支持的压根轮不到谈论 GIL。

[jhdxr]

@plqws 宗教都需要一些特别洗脑的 slogan

[vipppppp]

这应该是我在 v2 看到第 N 个吐槽 py 的贴了。。
作为一名 python 开发，每次都瑟瑟发抖，感受着来自各地的批斗。。
当下很多吹捧 py 的很多都是营销号或者网课吧。。。
上次一名 java 调来了我们组，直接把 java 的一套全部搬来 py 用，然后发现有些行不通，说不像 java 怎么样。。。
什么语言都好，都有他们本身的特点，不喜欢就不用，喜欢就用，拿一把水果刀去砍柴，怎么样都不合适把。

[z1154505909]

感觉挺好用的,作为第二语言,在处理一些事情上很方便

[noli]

@est 你的思路就是我们的解决办法之一，然而我们已决定逐步扔掉 python 的部分，用更高性能的 Go 或者 Rust 重写来替代，这又是一场腥风血雨。

这就是吐槽 GIL 的原因，没想到它能撑的时间这么短。

[est]

@noli py 被替换掉 很正常。可以大概说下你们用 py 处理什么业务过大规模么？

[youthfire]

太多人从程序员角度来思考了，毕竟是程序员论坛

作为一个外行，完全把写程序当成普通工作的效率提高方法的我来说，这个语言上手真的很快，即便运行速度有点慢，但开发周期很短，很快就能实现自己需要的一些功能。这本身就说明了问题。

[Tmac15]

喜欢就用，不喜欢就不用。有必要利用这样的方式来蹭热度吗？

[zr8657]

除了做项目用 java，其余的都不用。我根本不在乎那点内存，运行多花的那几秒到几十分钟，打完包以后几十上百 MB 的体积，只要他写起来简单就够了。人生苦短，我用 P____

[SpiderXiantang]

我现在感觉 Python 真的有立竿见影的功效 同样的程序 Java 需要花费两倍的时间实现

[SpiderXiantang]

但 Python 有一个比较明显的缺点重构不友好

[www5070504]

上边这一群说 python 是弱类型的在想什么呢 python 是强类型 就这种选手你还指望他的意见么

[lolizeppelin]

真要高性能的肯定要分布式, 分布式肯定要跨机的,都 TM 跨机了那多进程肯定也没问题的
所以 GIL 根本就不是什么大问题

python 慢的黑点根本不在 GIL 上..
python 的数字类型最少 28 字节,光这点就比别人慢了 7 倍了, 其他慢的地方更多
真要高性能,光循环 python 就败了还 G 什么 I 什么 L

那 GIL 喷 python 性能的根本就没算喷到点上。

[Jackeriss]

PY 一时爽，重构火葬场

[halk]

最大的优点就是各 linux 主流发行版都会内置，很方便日常的脚本操作
复杂的项目没有搞过

[gunavy]

大家说好就是好，说不好就不好，不取决于大家是 nb，还是 sb，跟着大家说就是了，😜。

[est]

@lolizeppelin 而且函数调用很重。。。各种 PyObjet 飞来飞去。

[XIVN1987]

优点：易学易用、库多

特点：动态类型（这条只能叫特点，不能叫缺点；因为动态类型和静态类型互有优缺点，动态类型的优点是灵活、缺点是工具软件没法静态分析你的代码，比如智能补全智障；静态类型的优缺点正好相反）

缺点：执行速度慢，，

[noli]

@lolizeppelin @est

十几二十个逻辑 CPU 同时抢一个锁恐怕你们没想过这样的数据结构怎么写。
幸好设计上一开始就没考虑过用 python 做这个计算，只是做外围的。
要是遇到 GIL 这样的查询恐怕排完队就天亮了。

可以透露的计算主业务是这样的，一个分布式的 R 树，将查询递归下降到各个不同的子树，这些子树的数据可能在同一个机器上，也可能在集群内另一台机器上。每个节点要主动分担查询热区的压力。

Python 的进程只是报告一下查询热区在哪里，但即使是这样，这个报告延迟还是太大了。

[seeker]

同感

[est]

@noli 这个场景怎么也不会拿 py 做吧。。。。。强人所难了。

[noli]

@est 看清楚，python 只是做报告热点的部分，简单来说思路就是在 UnixDomain socket 里面统计一下（当然这个统计可能运算也很大吧）

[est]

@noli 每个 py 进程做统计是去 poll 一个 domain socket 主要得看你们统计的操作是在 py 里做的，还是 py 只管采集不管计算。

[noli]

@est #95

肯定是采集和统计一起做的，必须和计算任务在同一个节点上，不然协调者本身还要跨网络这样太不可靠。

可能采集的时候 IO 可以效率提高，这部分或许还可以优化，或许上 asyncio 还可以提高性能。
但是既然决定要换掉 python, 再想这个有点迟了。

[est]

@noli py 那个小身板做你说这个事儿真不行。2333

[noli]

@est

我们也没想过一直永远都能靠 python 做这个，但没想到这么早就不行。
考虑到大家都懂点 python，用这个写应该容易理解不犯错，毕竟协调这部分逻辑反倒不容易讲得清。

直到我们发现它抗不住。

[agagega]

@secondwtq 智商兼容性 hhhhh

[est]

@noli 我现在只要稍微复杂一点的计算，比如用到 2 层 for 循环了，就得想办法 offload 到别的语言去。。。