建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 王德朕
審校 | Noe
無論是行業(yè)領(lǐng)袖還是學(xué)術(shù)研究人員，都吹捧Python是編程新手最好的語言之一。他們沒有錯，但這并不意味著Python不會讓編程新手們感到困惑。
以動態(tài)類型為例，看起來令人驚訝，Python 可以自己計算出變量可能獲得的值類型，而且不需要浪費一行代碼來聲明類型，這樣更快。
一開始是這樣的，然后你在某一行搞砸了，繼而導(dǎo)致你的整個項目在運行之前就崩潰了。
公平地說，其它語言許多都使用動態(tài)類型，但對于 Python 來說，這僅僅是一個糟糕清單的開始。
隱式聲明變量會使得代碼變得一團糟
幾年前，當(dāng)我開始攻讀博士學(xué)位時，我想進一步開發(fā)一個由同事編寫的現(xiàn)有軟件，我了解它的基本原理，甚至我的同事寫了一篇關(guān)于它的文檔。
但我仍然需要閱讀成千上萬行的Python代碼，以確保我知道每部分代碼做了什么，從而可以把我想到的新功能放在那里，這就是問題所在......
整個代碼中到處都是未被聲明的變量，為了理解每個變量的用途，我必須在整個文件中搜索它，更常見的是在整個項目中搜索它。
還有一個復(fù)雜的情況，變量通常在函數(shù)內(nèi)部被調(diào)用，但是當(dāng)函數(shù)被調(diào)用時，又會有其他的東西被調(diào)用……還有一個情況，一個變量可以與一個類交織在一起，這個類與另一個類的另一個變量相關(guān)聯(lián)，而另一個類又影響著一個完全不同的類……你明白了吧。
有這種經(jīng)歷的不止我一個,《Python之禪》中明確表示，顯式要比隱式好，但是在Python中做隱式變量太容易了，特別是在大型項目中，很快就會遇到麻煩。
可變類型無處不在--甚至在函數(shù)中也是如此
在Python中，你可以通過提供默認(rèn)值來定義具有可選參數(shù)的函數(shù)，不必再顯式聲明，像這樣：
def add_five(a, b=0):
return a + b + 5
我知道這是個鬧著玩的例子，但是你現(xiàn)在可以用一個或者兩個參數(shù)來調(diào)用這個函數(shù)，它還是可以工作的:
add_five(3) # 返回 8
add_five(3,4) # 返回 12
它能運行，是因為表達式 b = 0將 b 定義為一個整數(shù)，而整數(shù)是不可變的:
def add_element(list=[]):
list.append("foo")
return list
add_element() # 返回 ["foo"]，符合預(yù)期
到目前為止，一切正常，但是如果再次執(zhí)行它會發(fā)生什么？
add_element() # returns ["foo", "foo"]! wtf!
因為參數(shù)是一個列表，即列表 ["foo"] 已經(jīng)存在，Python 只是把它的東西附加到那個列表中，這樣做是因為列表與整數(shù)不同，列表是可變的類型。
常言道: “瘋狂就是一再重復(fù)相同的事情，卻期望得到不同的結(jié)果”（這句話常常被誤認(rèn)為是阿爾伯特· 愛因斯坦說的）。也可以說，Python 加上可選參數(shù)，加上可變對象簡直是瘋了。
類變量也不安全
如果你認(rèn)為這些問題僅限于可變對象作為可選參數(shù)的情況，那就錯了。
如果你進行面向?qū)ο缶幊蹋◣缀跛腥硕际沁@樣），那么類在Python代碼中無處不在，有史以來，類最有用的特性之一是——繼承。
這只是一個花哨的說法，如果你有一個具有某些屬性的父類，你可以創(chuàng)建一個子類繼承其屬性，像這樣：
class parent(object):
x = 1
class firstchild(parent):
pass
class secondchild(parent):
pass
print(parent.x, firstchild.x, secondchild.x) # 返回 1 1 1
這不是一個特別好的例子，所以不要將其復(fù)制到你的代碼項目中。關(guān)鍵是，子類繼承了x=1，因此我們可以調(diào)用它，并得到與父類相同的結(jié)果。
而且，如果我們改變了一個子類的x屬性，它應(yīng)該只改變那個子類。就像你在青少年時期染了頭發(fā)，它不會改變你父母或你兄弟姐妹的頭發(fā)，這樣就可以了。
firstchild.x = 2
print(parent.x, firstchild.x, secondchild.x) # 返回 1 2 1
你小時候媽媽染頭發(fā)的時候發(fā)生了什么? 你的頭發(fā)沒變，對吧？
parent.x = 3
print(parent.x, firstchild.x, secondchild.x) # 返回3 2 3
這是因為 Python 的方法解析順序，只要沒有特殊的說明，子類繼承了父類的一切，所以，在Python世界中，如果你不提前抗議，媽媽在做她的頭發(fā)時就會給你染發(fā)。
作用域有時候會反過來
接下來這個關(guān)卡已經(jīng)絆倒我很多次了。
在 Python 中，如果在函數(shù)內(nèi)部定義變量，那么這個變量不會在函數(shù)外部工作，有人說這超出了作用域：
def myfunction(number):
basenumber = 2
return basenumber*number
basenumber
## Oh no! This is the error:
# Traceback (most recent call last):
# File "", line 1, in
# NameError: name 'basenumber' is not defined
這應(yīng)該是相當(dāng)直觀的（不，我沒有在這一點上絆倒）。
那反過來呢？我的意思是，如果我在函數(shù)外面定義一個變量，然后在函數(shù)內(nèi)部引用它，會怎么樣？
x = 2
def add_5():
x = x + 5
print(x)
add_5()
## Oh dear...
# Traceback (most recent call last):
# File "", line 1, in
# File "", line 2, in add_y
# UnboundLocalError: local variable 'x' referenced before assignment
奇怪吧？如果阿爾伯特生活在一個有樹的世界里，并且阿爾伯特生活在一所房子里，那么阿爾伯特想必是知道樹是什么樣子的？（樹是x，阿爾伯特的房子是add_ 5()，阿爾伯特是5……）
我曾多次碰到這個問題，在一個類中，定義被另一個類調(diào)用的函數(shù)時，我花了很長時間才找到問題的根源。
這背后的想法是，函數(shù)內(nèi)部的x與外部的x是不同的，所以你不能就這樣改變它。就像如果阿爾伯特只是夢想著把樹變成橙色，那當(dāng)然不會讓樹實際變成橙色。
幸運的是，這個問題有一個簡單的解決方案，只要在 x 之前添加一個 global！
x = 2
def add_5():
global x
x = x + 5
print(x)
add_5() # works!
因此，如果你認(rèn)為作用域只能保護函數(shù)內(nèi)部的變量不受外部世界的影響，那么請再考慮一下。在 Python 中，外部世界受到局部變量的保護，就像阿爾伯特不能用他思想的力量把樹涂成橙色一樣。
在迭代列表時修改列表
我自己也遇到過幾次這樣的胡說八道。
想想這個:
mynumbers = [x for x in range(10)]
# this is [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
for x in range(len(mynumbers)):
if mynumbers[x]%3 == 0:
mynumbers.remove(mynumbers[x])
## Ew!
# Traceback (most recent call last):
# File "", line 2, in
# IndexError: list index out of range
這個循環(huán)不起作用，因為它每隔一段時間就會刪除列表中的一個元素。因此，列表的末端會向前移動，那么就不可能到達10號元素了，因為它已經(jīng)不在那里了!
一個簡單但方便的解決方案，為所有要刪除的元素分配一個不實用的值，然后在下一步中刪除它們。
但有一個更好的解決辦法:
mynumbers = [x for x in range(10) if x%3 != 0]
# that's what we wanted! [1, 2, 4, 5, 7, 8]
就一行代碼！
注意，我們已經(jīng)在上面的案例中，使用了 Python 列表解析式來調(diào)用列表。
它是方括號[] 中的表達式，是循環(huán)的簡寫形式，列表解析式通常比常規(guī)循環(huán)快一點，如果你處理的是大型數(shù)據(jù)集，這很酷。
在這里，我們只是添加了一個 if 子句 來告訴列表解析式，它不應(yīng)該包含被3整除的數(shù)字。
與上面描述的一些現(xiàn)象不同，即使初學(xué)者一開始可能會在這個這問題上磕磕絆絆，列表解析也不是 Python 糟糕的設(shè)計，而是 Python 的天才設(shè)計。
地平線上的一些光亮
在過去，當(dāng)遇到與 Python 相關(guān)的問題時，編碼并不是唯一的痛苦。Python的執(zhí)行速度也曾經(jīng)慢得令人難以置信，比大多數(shù)語言都慢2到10倍?，F(xiàn)在這種情況已經(jīng)好了很多，例如，Numpy 包在處理列表、矩陣等等方面非?？臁?/p>
使用Python，多進程也變得更加容易。這可以讓你使用所有的2個、16個或多個核心的計算機，而不是只有一個。我已經(jīng)在20個核心上運行過，它已經(jīng)為我節(jié)省了數(shù)周的計算時間。
此外，隨著機器學(xué)習(xí)在過去幾年中取得進展，Python 已經(jīng)表明，它還有很長的路要走。像 Pytorch 和 Tensorflow 這樣的軟件包使得機器學(xué)習(xí)變得非常容易，而其他語言正在努力跟上這一步。
這些年來 Python 已經(jīng)變得更好了，然而，這一事實并不能保證一個美好的未來，Python仍然不是傻瓜式的，請謹(jǐn)慎地使用它。
譯者介紹
王德朕，社區(qū)編輯，10年互聯(lián)網(wǎng)產(chǎn)研經(jīng)驗，6年IT教培行業(yè)經(jīng)驗。原K12教育上市公司產(chǎn)品經(jīng)理，技術(shù)博客專家，藍橋簽約作者，《滾雪球?qū)WPython》專欄作者，《爬蟲100例》專欄特約作者，78技術(shù)人社區(qū)發(fā)起者。
原文標(biāo)題：Python may be easy but it’s a goddamn mess
鏈接：https://thenextweb.com/news/python-may-be-easy-but-its-a-mess
文章題目：Python也許很友好，但它也容易弄得一團槽
當(dāng)前地址：http://m.5511xx.com/article/dhejgee.html
