为什么说”人生苦短,我用python解析“

发布网友 发布时间：2022-04-30 15:13

我来回答

共5个回答

懂视网 时间：2022-05-10 08:03

在Python开发领域流传着这样一句话：人生苦短，我用Python，这句话出自Bruce Eckel，原文是：Life is short，you need Python。使用过Python语言的程序员，或者从别的语言（比如Java）转换到Python开发的程序员或许对这句话的理解更加深刻。

例如长期使用过C和Java语言的程序员，在转向Python之后就会发现。采用Python进行机器学习方向的研发确实存在很多方便，主要体现在以下几个方面：（推荐学习：Python视频教程）

第一：代码量下降明显。

以机器学习为例，采用Java和Python完成同一个算法实现时，Python的实现代码量明显少于Java，有的下降幅度甚至超过一半以上。代码量的下降意味着开发周期的缩短，这在一定程度上减轻了程序员的开发负担。程序员可以把节省的时间做更多有意义的事情，比如做算法设计，或者用来学习等。

第二：开发方便。

Python语言完成代码实现的过程还是比较方便的，一个重要的原因是Python有丰富的库可以使用，比如在机器学习领域比较常见的库有Numpy、Scipy、matplotlib、pandas等，这些库提供了大量的基础实现，在编码的过程中，可以方便的使用这些库，从而避免了大量代码的编写过程。

第三：语言生态健全。

Python语言目前在Web开发、大数据开发、人工智能开发、后端服务开发和嵌入式开发等领域都有广泛的应用，成熟案例非常多，所以采用Python完成代码实现的时候往往具有较小的风险。

目前，伴随着大数据和人工智能的发展，目前Python语言的上升趋势非常明显，相信未来Python语言在产业互联网阶段会有更加广泛的应用。从这个角度来看，学习Python语言是个不错的选择。

更多Python相关技术文章，请访问Python教程栏目进行学习！

热心网友 时间：2022-05-10 05:11

Python具有丰富和强大的库。它常被昵称为胶水语言，能够把用其他语言制作的各种模块（尤其是C/C++）很轻松地联结在一起。常见的一种应用情形是，使用Python快速生成程序的原型（有时甚至是程序的最终界面），然后对其中[3] 有特别要求的部分，用更合适的语言改写，比如3D游戏中的图形渲染模块，性能要求特别高，就可以用C/C++重写，而后封装为Python可以调用的扩展类库。需要注意的是在您使用扩展类库时可能需要考虑平台问题，某些可能不提供跨平台的实现。
Python在设计上坚持了清晰划一的风格，这使得Python成为一门易读、易维护，并且被大量用户所欢迎的、用途广泛的语言。
Python的设计哲学是“优雅”、“明确”、“简单”。
Python开发者的哲学是“用一种方法，最好是只有一种方法来做一件事”。在设计Python语言时，如果面临多种选择，Python开发者一般会拒绝花俏的语法，而选择明确的没有或者很少有歧义的语法。由于这种设计观念的差异，Python源代码通常被认为比Perl具备更好的可读性，并且能够支撑大规模的软件开发。这些准则被称为Python格言。

热心网友 时间：2022-05-10 06:29

1.纵观 各大编程语言除了js 的语法简洁度和python 有得一拼的话 其他的就没谁了
2.既然能用1行代码就能解决问题，为啥要写10行，（不想手累脑累）
3.python也称胶水语言，和java ,c,等等衔接交互很顺畅，
没事的时候用python 跟着java程序员后面打打酱油 也不错

热心网友 时间：2022-05-10 08:04

Python是一种高级的编程语言。Python具有很多很好的特性。且Python语法简洁明快，例如利用缩进去取代类c语言中的{}，作为语句块的分割（刚开始我也以为这个很扯淡，但是自从用了Python，觉得这个真的大大减少了输入量）。同时Python还有大量的扩展库，免去自己从头开始的烦恼（Python的开放性使得很多人愿意写Python的库，而且Python作为传说中的'胶水语言'利用其它语言的库也是轻而易举）。所以选用Python语言编程，可以大幅减小代码量，可以更加快速简洁的开发项目。所以可以大量节约开发人员的时间。所以才有了
人生苦短，我用python
据传，开发相同的项目，python比Java要节约50%左右的开发时间，比C和C++节约的时间更多。不明白可追问。

热心网友 时间：2022-05-10 09:55

print ("人生苦短，我用python")
import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!