写在 Python 3.9 即将出世的前夕

哒呵呵

发布于 2020-05-12 15:44:25

5660

今天读 PyCoder's Weekly（ PyCoder's Weekly 会收集和整理一周内关于 Python 的最新文章和讨论，并发送给订阅者的邮箱）时候，发现 Python3.9 最新的版本3.9.0a5已经可以用了，有些感慨 Python3.8 还没用起来，Python3.9 就要来了，遂写下此文简单聊下 Python 这门语言。

要说起最喜欢的编程语言，那肯定是 Python 了，也因此在这个公众号写了很多关于 Python 的文章。虽说现在公众号的关注点在大数据和分布式系统方向，有点“怠慢”了 Python，但是不妨碍在公众号的前期一直在写关于 Python 的文章。

既然如此，最近为什么不写 Python 了呢？大概是觉得在熟练掌握一门语言后，就会感觉这门语言实在找不到什么新颖的点和读者聊聊，而我又不想人云亦云，随便翻译几篇官方文档里的文章，或者是从某些博客到处抄来抄去，因此就改写数据方向了，毕竟和大家聊下使用心得，和网上找不到的东西才有趣。

回到 Python 本身，平心而论，目前而言被各种营销号炒的太火了，说的神乎其神的，但是就找工作真实需求而言，学 Python 还不如学 Java。非要说，Python 有啥适用场景，可能就是所谓的机器学习和大数据了，但是对于这两个领域而言，Python 真的不是重点，比如机器学习更看重你的数学和算法知识，大数据领域的话可能更重视你对分布式系统的理解，Python 充其量算是锦上添花。抛开机器学习和大数据领域，Python 在后端领域真的没啥作为，国外知名点的也就是 YouTube 和 Instagram，在国内知名的可能就是豆瓣了，相对于 Java，Python 可选择的公司真的太少了。

既然 Python 有点言过其实了，但是为什么要学 Python 呢？学习一门编程语言不仅仅是关注它的语法，而更要关注语法背后的设计理念。相比于语法，讲实话，任何一门语言，除了非常复杂的 Rust 和 C++ 外，我想认真弄一个礼拜也就基本上可以干活了，特别是对于 Python ，需要的时间更短了。但是对于语法背后的设计理念，可能一年两年都不一定能理解。写了这么多年的 Python，笔者也不敢说搞懂了。

说到 Python 的设计理念，最重要的莫过于那 Python 之禅了（有趣的是，笔者在面试候选者的时候问到 Python 之禅，大部分候选者都一脸懵逼）。同样的 Python 之禅也深深影响了我对软件世界的看法。原本不想用 Python 之禅凑字数的，但是它写的实在太好了，还是在最后面附上吧。

其实 Python 之禅背后隐藏的哲学更是 Unix 的哲学，追求简单而优雅，“尽量用最简单的方法解决问题”。比如作为一个 Python 的使用者，写代码的时候应该思考的是你写的代码够不够通俗易懂，是不是足够简单，有没有另一种更优雅的方式去实现。当然这个在一定程度上局限了 Python 的性能，也同样引来了一堆人士吐槽 Python 性能差。幸运的是，Python 坚守了它的哲学，没有一味的追求性能。这里我要说下 Scala ，Scala 是一门多范式语言，按照 Scala 作者的看法，Scala 非常追求性能，可能同样的功能，不同的人写出来的代码性能会天高地别，但是同样的导致了 Scala 代码出了名的难看懂。萝卜西瓜各有所爱吧。

扯了这么多，最后再聊聊 Python3.9 本身，Python3.9 还在忙忙碌碌开发中，目前可能唯一比较值得期待的就是新的字典操作符，相比于前面几个版本确实少了很多杀手级更新，比如 Python3 刚出来时的Unicode 编码改版，Python3.5 的异步库（同样的这是 Python3 对 Python2 的“致命一击”，促使了 Python3 真正成为了新时代的 Python 标准，Python 于今年退出历史舞台），Python3.6的格式化字符串。当然啦，Python3.9 还没正式发布，一切都未可知，期待今年十月五号吧。

本文就此匆匆结束吧，感兴趣的读者可以读读文末附上的 Python3.9 的相关文章和 PEP 提案，不再此多说了。

Python 之禅

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!