今天讀
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！
附錄
https：//medium。com/@martin。heinz/new-features-in-python-3-9-you-should-know-about-14f3c647c2b4
https：//www。python。org/dev/peps/pep-0596/
