聊聊:Python

2020 年 04 月 22 日 阅读数: 76
聊聊:Python

Python 在最近的三年里发展的很火热,在 Tiobe 排行榜中一跃从前十的地位步入了前三,排行榜有被刷榜的可能,但商业市场不会,十年前培训市场上培训机构的主要课程是 PHP 与 Java,而如今 PHP 的有偿培训已经基本凉凉,反而你经常会在微信朋友圈以及路边小广告等到处看到 Python 的培训入口,可见 Python 的火热确实是货真价实。那么 Python 作为一门比 Java 还历史悠久的编程语言为什么会在最近的 2 到 3 年里突然的爆发呢?有人说这要感谢人工智能时代的到来,正是人工智能的提携才促使了 Python 的成长,这么说在我看来有一点点的表象,所以这里我们换个维度来聊聊:Python 的崛起。

 

在 Python 的 terminal 中输入 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.

万事开头难,毕竟你不是 Python 之父。

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

命名空间是一个精妙的设计,对此我们应该多多善用。

 

Pythoners 把这段话称之为:Python 之禅,从这段话中我们能深刻体会到 Python 的设计哲学——简洁、明了、推荐深度思考,但可快速解决眼前问题。正所谓大道至简,Python 从语言本身的词法、语法设计上就深刻的贯彻着这些思想,例如:完成相同的功能 Python 使用的代码行数几乎只相当于 Java 的 1/4,这种简洁对于没有形成代码肌肉记忆的初学者来说实在是太友好了。但是拥有其他语言丰富经验的 coder 初步接触 Python 的时候却经常拿 Python 的这种极致简洁语法进行抨击,例如:Python 为了做到语法足够简洁甚至连其他语言常用的代码块分隔符 "{}" 都省略了,而是通过代码缩进进行代码块的分隔,很多人感觉在 review 或 debug 代码的时候如果单个函数超过一屏,就无法友好的区分不同的代码块了,这给广大程序员带来了很大的困扰。其实会产生这种质疑主要是因为初学者对 Python 提出的简洁设计理念没有深刻的理解,Python 虽然简单直接,但并不推荐长篇大论的在一个函数里面写流水账,每一个函数或方法被视为代码中的一段原子操作,应该尽量的精简不易过于的余长,如果操作过于复杂,应该通过 class、function 进行抽象封装,如果超过一屏显然是没有抽象的到位或者深度思考的不够,Python 这样设计代码块的一个好处是可以更高效的一揽全局看到整体操作的全貌。

 

早期的计算机多数都是科学家或大型机构在使用,多用于研究、统计等复杂的计算操作,那时为了高效的与计算机进行交互必须通过编程语言来进行。随着时代的发展计算机经过产品的不断迭代逐步的进入了我们寻常人家,现如今即使没有任何编程经验的普通人,也可以通过计算机的辅助高效的完成部分工作。而与此同时编程语言也已经经过了几个时代的变迁:机器语言、汇编语言、现代编程语言(以 C 语言的诞生为标志),甚至还同步催生出了程序员这样一个群体。但是慢慢的人们发现编程语言并没有像计算机一样变得普惠,而是不得不依赖程序员这个群体的转义才能完成相关的编程工作,而要进入程序员这个群体的门槛也是非常的高(至少在我 24 岁之前是这样认为的),网上也经常看到有人吐槽程序员这个行业苦啊!首先,你要掌握至少一门编程语言,两门以上优先考虑(想一想我们小的时候用了几年才学会说汉语,写汉字)。其次,你还要掌握几种设计模式并灵活的将单例啊、工厂啊、代理啊等等设计模式运用到平时的编程工作中。最后还要有算法基础,程序员面试的时候如果排序啊、查找啊、递归啊等算法没答上来可能直接就被拒之门外了。这也间接的导致不少科研人员纵使掌握众多数学公式、算法、行业经验,但是因为 C 语言编程能力不过关不得不再依赖一些 C 程序员同步辅助完成相关的科研工作。编程语言因此不得不让普通人怀疑到底是来解决问题的还是来制造问题的?而一般人看到别人面对 C 语言的窘境时,一定是劝诫别人努力学习多多练习,同时送上一本《21天精通 C 语言》以表关爱,然而有一个人却不然,他立志于发明一门新的语言,这门语言既像 C 语言一样可以对计算机资源全面的掌控,又使用起来十分的简单,使人轻轻松松写一些小工具。这个人便是 Guido van Rossum。1989 的冬天 Guido 为了打付无聊的假期使圣诞节过得有意义便开始编写 Python 的解析器(你看大神的度假方式就是特别啊),而解析器正是由 C 语言编写,两年后 Python 的第一个版本便顺利发布了,Python 从设计之初就十分的注意与 C 语言之间的交互,所以从最开始的版本至今一直可以非常方便的对 C 语言的类库进行调用,这个决定对最近几年 Python 的蓬勃发展起到了至关重要的作用。因此,假如有这样一门语言,开发者学习几天便可以轻轻松松的写出完成指定功能的小工具,还可以通过更便捷的方式对大量的科学计算 C 库进行封装调用,语言原生携带的 dict,list,map,reduce,filter 等等特性与数据分析处理又十分的契合,如果你是人工智能的从业人员你难道会不选择 Python 么?所以在我看来 Python 这几年的蓬勃发展,并非是单方面幸运的受人工智能兴起的提携,更多的是从 Python 语言诞生之初面对要解决的问题所奠定的定位,以及过去 30 年间在统计学领域不断发展的 Python 生态,让人工智能不得不暂时将 Python 作为第一语言。

纵使关注成本的人可能会考虑 Python 所占用的 CPU、内存等硬件成本,关注执行效率的人可能会担忧 Python 的 GIL,但是正所谓“人生苦短,请用 Python”,跟人生相比,你还会在乎这些么?

用户头像

bytesir

关注

职业打杂儿,业余编程。。。 2017.10.17 加入

还未添加个人简介

评论

发布
暂无评论
聊聊:Python