V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
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
noli
V2EX  ›  Python

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

  •  
  •   noli · 2019-06-30 11:28:09 +08:00 · 14951 次点击
    这是一个创建于 1983 天前的主题,其中的信息可能已经有所发展或是发生改变。
    看完标题请先冷静。

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

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

    求一个我没有想到的 Python 的优点
    172 条回复    2019-07-12 21:56:57 +08:00
    1  2  
    Wincer
        1
    Wincer  
       2019-06-30 11:35:47 +08:00 via Android   ❤️ 1
    Python 除了标准库之外,优秀的第三方库也不少吧? numpy,ss
    GIL 是 Python 实现的锅,并不是所有的 Python 实现都是带有 GIL 的
    还有 Python 静态类型是什么鬼?楼主分不清静态类型和动态类型,弱类型和强类型语言的区别吗
    Vegetable
        2
    Vegetable  
       2019-06-30 11:38:06 +08:00   ❤️ 1
    你这个不会引战,大家只会单方面反驳你.
    python 当然有很多缺点,除了世界上最好的语言,每一个语言都有自己的缺点.
    也很少有哪个语言有独一无二的优点,所以都是整合起来看的.

    比如 python 入门更简单,适用范围广,开发速度快等等这些优点,可能不是他独有的,但是偏偏做到了恰到好处.
    Mohanson
        3
    Mohanson  
       2019-06-30 11:38:27 +08:00 via Android
    场景不同,用不同的语言。你要硬拿他写 curd, py 是真的垃圾。但你要拿他写 demo,验证算法,验证工程可行性, 能节约你无数的时间。

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

    我曾花了 10 天左右用 pure python, 且没用任何第三方库,甚至标准库都没怎么用,裸写了一个 webassembly 虚拟机,见上面的帖子。
    lihongjie0209
        4
    lihongjie0209  
       2019-06-30 11:39:44 +08:00
    脚本语言而已, 别太神化
    pythonee
        5
    pythonee  
       2019-06-30 11:41:38 +08:00 via iPhone
    同感
    niubee1
        6
    niubee1  
       2019-06-30 11:43:38 +08:00
    没理解到优点可能因为卤煮不大聪明, 呵呵, 开玩笑的, 因为都说聪明的程序员会选择 Python, 不是工作语言也会是排第二的辅助语言
    Jirajine
        7
    Jirajine  
       2019-06-30 11:44:18 +08:00 via Android
    说真的 Python 设计真的挺优雅的。要是有个编译器,效率高些就更好了。
    niubee1
        8
    niubee1  
       2019-06-30 11:49:44 +08:00
    @Jirajine 有编译器, 自己编译自己,Pypy
    jeffersonpig
        9
    jeffersonpig  
       2019-06-30 11:49:54 +08:00
    你不需要去理解为什么别人觉得它是个好语言,你关注它对你而言是不是好语言就好。你是在为你自己的需要而使用,不是为别人。
    Sylv
        10
    Sylv  
       2019-06-30 11:53:41 +08:00
    我想说:真香。
    Cooky
        11
    Cooky  
       2019-06-30 12:01:11 +08:00 via Android   ❤️ 1
    没有大公司后台坐镇的通用型语言能活成这样很难得了
    impl
        12
    impl  
       2019-06-30 12:14:15 +08:00 via Android
    95 年的语言,现在还这么流行,已经很牛逼了。看看同是脚本语言的 perl,ruby 都歇菜了。。
    impl
        13
    impl  
       2019-06-30 12:15:04 +08:00 via Android
    95 年 -> 91 年
    littlewing
        14
    littlewing  
       2019-06-30 12:18:01 +08:00 via iPhone
    弱类型是最恶心的
    clino
        15
    clino  
       2019-06-30 12:22:20 +08:00 via Android
    觉得不好就不用咯

    我的看法是 python 的开发效率高,写起来舒服,足够成为我选择的理由了。如果要抠效率的场合就不合适了。
    la2la
        16
    la2la  
       2019-06-30 12:27:23 +08:00
    @Vegetable 真的只是入门简单,写比较优雅的 python 开发,感觉比 java 还要难啊。尤其是多人开发,没有啥规范的时候 o(╯□╰)o
    kxiaong
        17
    kxiaong  
       2019-06-30 12:31:14 +08:00
    喷 GIL 不会引战,python 在 GIL 问题上就是反进化的。最该喷的是,都 9012 年了,社区还不努力解决这个问题。

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

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

    别把语言当作自己的瓶颈和局限。 在合适的地方用合适的技术就好。 看不惯 GIL 就自己去优化, 搞不定就换别的语言。 喷不解决问题本身。
    fy
        18
    fy  
       2019-06-30 12:31:53 +08:00
    理由举了好几条,但是唯独最重要的东西没说:
    好用吗?方便吗?

    好用就用 不好用就不用
    FrankHB
        19
    FrankHB  
       2019-06-30 12:36:27 +08:00
    @Wincer
    既然知道 GIL 是具体实现为主的锅了,也请注意 numpy 的可用性长期依赖具体的实现而不是 Python 语言。
    虽然 LZ 少根筋,也别把弱类型这种民科概念堂皇地提出来。
    xrlin
        20
    xrlin  
       2019-06-30 12:39:15 +08:00 via Android
    静态类型和动态类型都分不开。。。python 第三方库质量挺高的,django flask numpy 之类的,文档也齐全,gil 和效率确实是个问题,性能要求高的不是 python 的使用场景。
    oblivious
        21
    oblivious  
       2019-06-30 12:46:23 +08:00   ❤️ 3
    Python 的一个优点就是:极大的简化了不需要开发项目的研究人员编程的学习曲线。

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

    现在的科研人员:花 6h 时间直接学会 py 所有基础功能,然后可以开心的魔改各种别人的代码了。
    Takamine
        22
    Takamine  
       2019-06-30 12:52:00 +08:00 via Android
    没有大括号,一个标尺解决问题的语言还不够好吗。:doge:
    janxin
        23
    janxin  
       2019-06-30 13:07:29 +08:00
    @kxiaong 不不不,2019 年了,应该会在明年绕开 GIL (支持多虚拟机在单进程中运行

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

    作为纯社区支持,确实已经很不容易了,看看隔壁 pypy 那可怜的...
    ch3nOr
        24
    ch3nOr  
       2019-06-30 13:17:17 +08:00 via iPhone
    @littlewing
    但是 Python 是强类型的啊
    FrankHB
        25
    FrankHB  
       2019-06-30 13:37:56 +08:00
    @Takamine 一样得被 PEP-8 教做人。
    Osk
        26
    Osk  
       2019-06-30 13:40:27 +08:00 via Android
    python 不是动态强类型吗???
    noli
        27
    noli  
    OP
       2019-06-30 14:03:03 +08:00
    @Wincer #1

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


    @Vegetable #2

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

    @Mohanson #3

    我也写过寄存器式虚拟机。最难解决的问题是执行效率。
    用 python 写有什么优势吗?
    secondwtq
        28
    secondwtq  
       2019-06-30 14:18:17 +08:00 via iPad   ❤️ 5
    @noli numpy 是一个软件,GPU 是一种硬件,你既然写过虚拟机应该知道这俩是没法拿来比的

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

    之所以现在吹 Python 的比吹 PHP、Ruby 之类的多,因为 Python 的适用范围比 PHP 广,智商兼容性比 Ruby 高
    Vegetable
        29
    Vegetable  
       2019-06-30 14:22:45 +08:00   ❤️ 1
    @noli #27

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

    开发速度快就是快吧,我觉得没什么可讨论的,在脚本语言里肯定不是最优秀的,leetcode 感受比较深,只有 python 是最适合刷题目的.更能专注于问题本身,其他的语言哪怕再熟练也不得不多写很多字.
    mywaiting
        30
    mywaiting  
       2019-06-30 14:24:08 +08:00
    除了 GIL,以及 GIL 导致的性能低下问题,我觉得 Python 没有太多可以喷的地方

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

    要说 Python 最大的好处,就是这语言几乎不限制你的表达,怎么喜欢怎么来
    FrankHB
        31
    FrankHB  
       2019-06-30 14:34:02 +08:00   ❤️ 1
    @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
        32
    charlie21  
       2019-06-30 14:39:10 +08:00
    某某语言 是给那些驾驭不了 xxxx 的人用的,比如 科研人员、数据科学家

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

    python 奥迪双钻 你的伙伴

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

    -
    charlie21
        33
    charlie21  
       2019-06-30 14:43:06 +08:00
    也不是说 python 不好
    玩玩可以,别耽误了正途 ( C++, C, Java, C# ) 。你一个高级工程师 业余爱好喜欢玩四驱车 也可以。但你不能说 你就是一个专业玩四驱车的,你就是高级工程师了
    liprais
        34
    liprais  
       2019-06-30 14:44:07 +08:00   ❤️ 1
    面向对象一坨屎,缩进是语法的一部分,还有那精神分裂的 api 设计,更别提那包分发机制,这语言哪里好了.....
    FrankHB
        35
    FrankHB  
       2019-06-30 14:46:23 +08:00   ❤️ 2
    @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
        36
    youngxu  
       2019-06-30 14:48:45 +08:00 via Android
    至少对科研人员来讲很友好,简单易上手。就拿计算物理课程说,前几届学长用的是 fortran,但我们这一届换成了 python,(人的)效率提升不是一点半点
    sazima
        37
    sazima  
       2019-06-30 14:53:24 +08:00
    写过 python 写过 java, 最后还是选择了 python 的简洁
    charlie21
        38
    charlie21  
       2019-06-30 15:00:33 +08:00
    什么编程语言选择,哪这么多内心戏?

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

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

    -
    VinsonGuo
        39
    VinsonGuo  
       2019-06-30 15:02:39 +08:00
    已经被 java 的 ide 惯坏了,想问下 py 大佬们 ide 经常不提示是怎么解决的,难道那么多 api 都能记下来?
    charlie21
        40
    charlie21  
       2019-06-30 15:09:37 +08:00
    ( 当然,在另一群人的眼里,他们修氪星β域长江大桥,他们眼里 java 才是四驱车工具箱,python 才是正经工具,
    他们也是修桥的 -- 玩具桥也是桥、氪星β域长江大桥 也是 桥 -- 所以他们不想拿四驱车工具箱凑合,所以 选择了 python ) 滑稽

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

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

    所以 问题来了:你是地球人还是氪星人
    mywaiting
        41
    mywaiting  
       2019-06-30 15:15:40 +08:00
    @FrankHB #35 既然 at 了就得回复吧

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

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

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

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

    限于水平,目前我确实还没有太多能限制表达方面的发现
    qcts33
        42
    qcts33  
       2019-06-30 15:19:21 +08:00   ❤️ 2
    @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
        43
    FreeEx  
       2019-06-30 15:37:05 +08:00 via iPhone
    @VinsonGuo 所以写 py 需要双屏,一个看文档,一个写代码,没文档是写不了 py 的。
    gsj987
        44
    gsj987  
       2019-06-30 16:37:38 +08:00
    我是习惯遇到需求先写个 python 脚本,用简单的数据或者场景模拟一下,然后直接并入 django 写的系统提供对外服务。非常简单。

    当然作为写了十年 python 的程序员,我也不得不说 python 在很多方面有他的缺点,别的不说,就说这个语法吧,代码一多就一坨一坨的,没啥优美性可言。
    exceloo
        45
    exceloo  
       2019-06-30 16:38:58 +08:00
    脚本语言,即时上手,在服务器上只要环境搭好,想开一个小脚本,随写随用,主要是方便吧。
    Yourshell
        46
    Yourshell  
       2019-06-30 16:52:29 +08:00
    可是跟其它语言比起来也没那么差不是?
    FrankHB
        47
    FrankHB  
       2019-06-30 17:26:03 +08:00
    @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
        48
    anonymous256  
       2019-06-30 19:58:15 +08:00 via Android
    “真实项目中也不太可能只用标准库解决问题”,不同意的。

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

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

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

    楼上说代码一坨一坨的,那个应该是自己代码的问题了。我以前也那样,现在写的函数大多很短。一个功能就一个函数,该拆分就拆分。和语言无关
    necomancer
        49
    necomancer  
       2019-06-30 21:05:25 +08:00
    @oblivious 作为科研党必须给个赞
    akira
        50
    akira  
       2019-06-30 21:25:08 +08:00
    引用我以前常对人说的 如果你觉得 xxxx 没什么用,那说明你没有这个需求

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

    或许你是习惯了用锤子,但是 py 是个扳手,那不能用锤子的标准来衡量扳手啊
    necomancer
        51
    necomancer  
       2019-06-30 21:28:53 +08:00
    @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
        52
    tairan2006  
       2019-06-30 21:35:17 +08:00
    最大的作用是快速实现原型
    ps1aniuge
        53
    ps1aniuge  
       2019-06-30 22:13:46 +08:00
    这里贴 py 代码方便吗?
    txy3000
        54
    txy3000  
       2019-06-30 23:25:53 +08:00 via Android
    没有完美的语言 只有合适的语言
    选对了事半功倍 选错了来 V2EX 吐槽 🐶
    est
        55
    est  
       2019-07-01 00:12:56 +08:00
    拿 GIL 说事的,贴一下你们服务器监控,究竟多少核心有多少个并行任务?

    2 CPU 那种垃圾云主机或者 docker 镜像洗洗睡吧。还轮不到 GIL 成为瓶颈。
    russian
        56
    russian  
       2019-07-01 00:14:30 +08:00
    我最早写 c++,后来写 python, java, javascript。

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

    速度就是金钱。
    noli
        57
    noli  
    OP
       2019-07-01 00:23:33 +08:00
    @est #55

    我司产品所有的锁,都是改过的,都不会让系统线程进入等待。
    请问够资格吗?
    mumbler
        58
    mumbler  
       2019-07-01 00:30:09 +08:00 via Android
    我现在需要用一个脚本完成某些任务,不用 python,你给推荐个其他没毛病的语言?
    est
        59
    est  
       2019-07-01 00:32:06 +08:00
    @noli 一个文件系统 io 就会等待了。
    noli
        60
    noli  
    OP
       2019-07-01 00:41:32 +08:00
    @est #59

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

    那些说 Python 开发快的,我估计都是业务量不大,连原型都跑不垮的穷鬼公司吧。
    VEEX6
        61
    VEEX6  
       2019-07-01 00:46:10 +08:00 via Android
    油管体验过吧,这一点就足够
    noli
        62
    noli  
    OP
       2019-07-01 00:57:51 +08:00
    @mumbler Powershell 怎么样?
    jokerlee
        63
    jokerlee  
       2019-07-01 00:58:51 +08:00 via Android
    语言的本身设计的好坏和市场份额内什么直接的关系,时势造英雄,合适的时间出现在合适的位置上就成了。
    jokerlee
        64
    jokerlee  
       2019-07-01 00:59:53 +08:00 via Android
    这个世界上就没有所谓的好语言,只有合适的语言
    iwanghang
        65
    iwanghang  
       2019-07-01 01:01:42 +08:00
    俗话说 PHP 是最好的语言啊
    jokerlee
        66
    jokerlee  
       2019-07-01 01:10:25 +08:00 via Android
    说一个 python 的优点吧,他是 linux 发行版里所有预装语言里最容易上手的,就算不会写大概率也看得懂。
    jim9606
        67
    jim9606  
       2019-07-01 03:01:29 +08:00   ❤️ 1
    对于 python 小白入坑,可以很快就利用第三方库弄出个简单的 GUI 应用,还不用怎么理解计算机组成原理(非专业的一般学到这就可以拿去干活了),这是很有成就感的事,在这点上别的语言好像只有 js 能追上。

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

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

    GIL 是 CPython 特有的,PyPy 就没这个问题,也是个历史遗留问题。
    plqws
        68
    plqws  
       2019-07-01 07:21:54 +08:00
    python 的标准库混乱,全局函数和面向对象混用,某些语法晦涩不明,依赖 /包管理稀烂,2->3 也是个问题。始终无法理解为什么能吹得神乎其神,什么 zen of python 更是大笑话
    fundebug
        69
    fundebug  
       2019-07-01 09:44:10 +08:00
    python 的缩进简直变态
    est
        70
    est  
       2019-07-01 10:07:30 +08:00
    @noli 业务量大遇到 GIL,那肯定不是 IO 密集,而是计算密集。计算密集,就算没 GIL,py 那个小身板性能啥没法干啊。。。非 python 进程与 python 进程间数据交换你们用的 multiprocessing 之类的直接传递对象么?如果换成消息队列呢?
    est
        71
    est  
       2019-07-01 10:08:43 +08:00
    @jim9606 pypy 有 GIL 这个问题。

    GIL 是支持内核线程的语言特有的问题。比如 nodejs 这类连原生线程都不支持的压根轮不到谈论 GIL。
    jhdxr
        72
    jhdxr  
       2019-07-01 10:17:46 +08:00
    @plqws 宗教都需要一些特别洗脑的 slogan
    vipppppp
        73
    vipppppp  
       2019-07-01 10:23:27 +08:00
    这应该是我在 v2 看到第 N 个吐槽 py 的贴了。。
    作为一名 python 开发,每次都瑟瑟发抖,感受着来自各地的批斗。。
    当下很多吹捧 py 的很多都是营销号或者网课吧。。。
    上次一名 java 调来了我们组,直接把 java 的一套全部搬来 py 用,然后发现有些行不通,说不像 java 怎么样。。。
    什么语言都好,都有他们本身的特点,不喜欢就不用,喜欢就用,拿一把水果刀去砍柴,怎么样都不合适把。
    z1154505909
        74
    z1154505909  
       2019-07-01 10:23:32 +08:00
    感觉挺好用的,作为第二语言,在处理一些事情上很方便
    noli
        75
    noli  
    OP
       2019-07-01 10:23:50 +08:00 via iPhone
    @est 你的思路就是我们的解决办法之一,然而我们已决定逐步扔掉 python 的部分,用更高性能的 Go 或者 Rust 重写来替代,这又是一场腥风血雨。

    这就是吐槽 GIL 的原因,没想到它能撑的时间这么短。
    est
        76
    est  
       2019-07-01 10:26:21 +08:00
    @noli py 被替换掉 很正常。可以大概说下你们用 py 处理什么业务过大规模么?
    youthfire
        77
    youthfire  
       2019-07-01 10:27:29 +08:00
    太多人从程序员角度来思考了,毕竟是程序员论坛

    作为一个外行,完全把写程序当成普通工作的效率提高方法的我来说,这个语言上手真的很快,即便运行速度有点慢,但开发周期很短,很快就能实现自己需要的一些功能。这本身就说明了问题。
    Tmac15
        78
    Tmac15  
       2019-07-01 10:33:01 +08:00
    喜欢就用,不喜欢就不用。有必要利用这样的方式来蹭热度吗?
    zr8657
        79
    zr8657  
       2019-07-01 10:38:38 +08:00
    除了做项目用 java,其余的都不用。我根本不在乎那点内存,运行多花的那几秒到几十分钟,打完包以后几十上百 MB 的体积,只要他写起来简单就够了。人生苦短,我用 P____
    SpiderXiantang
        80
    SpiderXiantang  
       2019-07-01 10:42:36 +08:00
    我现在感觉 Python 真的有立竿见影的功效 同样的程序 Java 需要花费两倍的时间实现
    SpiderXiantang
        81
    SpiderXiantang  
       2019-07-01 10:45:10 +08:00
    但 Python 有一个比较明显的缺点重构不友好
    www5070504
        82
    www5070504  
       2019-07-01 11:06:52 +08:00
    上边这一群说 python 是弱类型的在想什么呢 python 是强类型 就这种选手你还指望他的意见么
    lolizeppelin
        83
    lolizeppelin  
       2019-07-01 11:07:50 +08:00
    真要高性能的肯定要分布式, 分布式肯定要跨机的,都 TM 跨机了那多进程肯定也没问题的
    所以 GIL 根本就不是什么大问题

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

    那 GIL 喷 python 性能的根本就没算喷到点上。
    Jackeriss
        84
    Jackeriss  
       2019-07-01 11:34:31 +08:00
    PY 一时爽,重构火葬场
    halk
        87
    halk  
       2019-07-01 14:12:03 +08:00
    最大的优点就是各 linux 主流发行版都会内置,很方便日常的脚本操作
    复杂的项目没有搞过
    gunavy
        88
    gunavy  
       2019-07-01 14:17:43 +08:00
    大家说好就是好,说不好就不好,不取决于大家是 nb,还是 sb,跟着大家说就是了,😜。
    est
        89
    est  
       2019-07-01 14:53:39 +08:00
    @lolizeppelin 而且函数调用很重。。。各种 PyObjet 飞来飞去。
    XIVN1987
        90
    XIVN1987  
       2019-07-01 15:10:41 +08:00
    优点:易学易用、库多

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

    缺点:执行速度慢,,
    noli
        91
    noli  
    OP
       2019-07-01 15:18:58 +08:00
    @lolizeppelin @est

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

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

    Python 的进程只是报告一下查询热区在哪里,但即使是这样,这个报告延迟还是太大了。
    seeker
        92
    seeker  
       2019-07-01 15:22:45 +08:00
    同感
    est
        93
    est  
       2019-07-01 15:27:29 +08:00
    @noli 这个场景怎么也不会拿 py 做吧。。。。。强人所难了。
    noli
        94
    noli  
    OP
       2019-07-01 15:31:15 +08:00
    @est 看清楚,python 只是做报告热点的部分,简单来说思路就是在 UnixDomain socket 里面统计一下(当然这个统计可能运算也很大吧)
    est
        95
    est  
       2019-07-01 15:34:12 +08:00
    @noli 每个 py 进程做统计是去 poll 一个 domain socket 主要得看你们统计的操作是在 py 里做的,还是 py 只管采集不管计算。
    noli
        96
    noli  
    OP
       2019-07-01 15:49:16 +08:00
    @est #95

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

    可能采集的时候 IO 可以效率提高,这部分或许还可以优化,或许上 asyncio 还可以提高性能。
    但是既然决定要换掉 python, 再想这个有点迟了。
    est
        97
    est  
       2019-07-01 15:54:07 +08:00
    @noli py 那个小身板做你说这个事儿真不行。2333
    noli
        98
    noli  
    OP
       2019-07-01 16:01:38 +08:00
    @est

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

    直到我们发现它抗不住。
    agagega
        99
    agagega  
       2019-07-01 16:04:17 +08:00 via iPhone
    @secondwtq 智商兼容性 hhhhh
    est
        100
    est  
       2019-07-01 16:05:32 +08:00
    @noli 我现在只要稍微复杂一点的计算,比如用到 2 层 for 循环了,就得想办法 offload 到别的语言去。。。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3549 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 04:48 · PVG 12:48 · LAX 20:48 · JFK 23:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.