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

[noli]

看完标题请先冷静。

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

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

求一个我没有想到的 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 向兼容。

[dushixiang]

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

[keenkiller]

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

[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 开发快的，我估计都是业务量不大，连原型都跑不垮的穷鬼公司吧。