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

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

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

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

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

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

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

脚本语言而已, 别太神化

同感

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

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

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

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

我想说：真香。

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

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

95 年 -> 91 年

弱类型是最恶心的

觉得不好就不用咯

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

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

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

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

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

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

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

好用就用 不好用就不用

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

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

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

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

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

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

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

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

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

@littlewing 但是 Python 是强类型的啊

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

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

@Wincer #1

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


@Vegetable #2

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

@Mohanson #3

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

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

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

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

@noli #27

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

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

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

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

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

@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 都搞砸了不少事情），而且流行起来也相当偶然了。

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

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

python 奥迪双钻 你的伙伴

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

-

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

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

@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 的另一个反智问题，也是屑。）

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

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

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

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

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

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

-

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

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

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

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

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

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

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

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

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

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

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

@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 向兼容。

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

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

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

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

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

@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

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

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

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

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

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

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

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

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

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

@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，生态算硬伤。

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

这里贴 py 代码方便吗？

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

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

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

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

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

度就是金钱。

@est #55

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

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

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

@est #59

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

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

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

@mumbler Powershell 怎么样？

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

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

俗话说 PHP 是最好的语言啊

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

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

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

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

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

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

python 的缩进简直变态

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

@jim9606 pypy 有 GIL 这个问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PY 一时爽，重构火葬场

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

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

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

优点：易学易用、库多

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

缺点：执行速度慢，，

@lolizeppelin @est

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

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

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

同感

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

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

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

@est #95

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

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

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

@est

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

直到我们发现它抗不住。

@secondwtq 智商兼容性 hhhhh

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