您好,登錄后才能下訂單哦!
本篇內容主要講解“Python是強類型語言還是弱類型語言”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Python是強類型語言還是弱類型語言”吧!
1、動靜類型與強弱類型
很多讀者應該都熟悉動態類型與靜態類型,但是很多人也會把它們跟強弱類型混為一談,所以我們有必要先作一下概念上的澄清。
這兩組類型都是針對于編程語言而言的,但關注的核心問題不同。
對于“動靜類型”概念,它的核心問題是“什么時候知道一個變量是哪種類型”?
一般而言,在編譯期就確定變量類型的是靜態類型語言,在運行期才確定變量類型的則是動態類型語言。
例如,某些語言中定義函數“int func(int a){…}”,在編譯時就能確定知道它的參數和返回值是 int 類型,所以是靜態類型;而典型如 Python,定義函數時寫“def func(a):…”,并不知道參數和返回值的類型,只有到運行時調用函數,才最終確定參數和返回值的類型,所以是動態類型
對于“強弱類型”概念,它的核心問題是“不同類型的變量是否允許隱式轉化”?
一般而言,編譯器有很少(合理)隱式類型轉化的是強類型語言,有較多(過分)隱式類型轉化的是弱類型語言。
例如,Javascript 中的 "1000"+1會得到字符串“10001”,而 "1000"-1則會得到數字 999,也就是說,編譯器根據使用場合,對兩種不同類型的對象分別做了隱式的類型轉化,但是相似的寫法,在強類型語言中則會報類型出錯。(數字與字符串的轉化屬于過分的轉化,下文會再提到一些合理的轉化。)
按照以上的定義,有人將常見的編程語言畫了一張分類圖:
按強弱類型維度劃分,可以歸納出:
強類型:Java、C#、Python、Ruby、Erlang(再加GO、Rust)……
弱類型:C、C++、Javascript、Perl、PHP、VB……
2、過去的強弱類型概念
動靜類型的概念基本上被大家所認可,然而,強弱類型的概念在問答社區、技術論壇和學術討論上卻有很多的爭議。此處就不作羅列了。
為什么會有那么多爭議呢?
最主要的原因之一是有人把它與動靜類型混用了。
最明顯的一個例子就是 Guido van Rossum 在 2003 年參加的一個訪談,它的話題恰好是關于強弱類型的(Strong versus Weak Typing):
但是,他們談論的明顯只是動靜類型的區別。
訪談中還引述了 Java 之父 James Gosling 的話,從他的表述中也能看出,他說的“強弱類型”其實也是動靜類型的區分。
另外還有一個經典的例子,C 語言之父 Dennis Ritchie 曾經說 C 語言是一種“強類型但是弱檢查”的語言。如果對照成前文的定義,那他其實指的是“靜態類型弱類型”。
為什么這些大佬們會有混淆呢?
其實原因也很簡單,那就是在當時還沒有明確的動靜類型與強弱類型的概念之分!或者說,那時候的強弱類型指的就是動靜類型。
維基百科上給出了 1970 年代對強類型的定義,基本可以還原成前文提到的靜態類型:
In 1974, Liskov and Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."[3] In 1977, Jackson wrote, "In a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types."[4]
前面幾位編程語言之父應該就是持有類似的觀念。
不過,大佬們也意識到了當時的“強弱類型”概念并不充分準確,所以 Dennis Ritchie 才會說成“強類型但是弱檢查”,而且在訪談中,Guido 也特別強調了 Python 不應該被稱為弱類型,而應該說是運行時類型(runtime typing) 。
但是在那個早期年代,基本上強弱類型就等同于動靜類型,而這樣的想法至今仍在影響著很多人。
3、現在的強弱類型概念
早期對于編程語言的分類其實是混雜了動靜與強弱兩個維度,但是,它們并不是一一對應重合的關系,并不足以表達編程語言間的區別,因此就需要有更為明確/豐富的定義。
有人提出了“type safety”、“memory safety”等區分維度,也出現了靜態檢查類型和動態檢查類型,與強弱類型存在一定的交集。
直到出現 2004 年的一篇集大成的學術論文《Type Systems》(出自微軟研究院,作者 Luca Cardelli),專門研究編程語言的不同類型系統:
論文中對于強弱檢查(也即強弱類型)有一個簡短的歸納如下:
Strongly checked language: A language where no forbidden errors can occur at run time (depending on the definition of forbidden error).
Weakly checked language: A language that is statically checked but provides no clear guarantee of absence of execution errors.
其關鍵則是程序對于 untrapped errors 的檢查強度,在某些實際已出錯的地方,弱類型程序并不作捕獲處理,例如 C 語言的一些指針計算和轉換,而《C 程序員十誡》的前幾個都是弱類型導致的問題。
論文對于這些概念的定義還是比較抽象的,由于未捕獲的錯誤(untrapped errors)大多是由于隱式類型轉換所致,所以又演化出了第一節中的定義,以隱式類型轉換作為判斷標準。
如今將“對隱式類型轉換的容忍度”作為強弱類型的分類標準,已經是很多人的共識(雖然不夠全面,而且有一些不同的聲音)。
例如,維基百科就把隱式類型轉換作為弱類型的主要特點之一:
A weakly typed language has looser typing rules and may produce unpredictable results or may perform implicit type conversion at runtime.
例如,以 Python 為例,社區的主流看法認為它是強類型語言,而判斷的標準也是看隱式類型轉換。
例子有很多,比如 Python 官方的 wiki,它專門回答了Why is Python a dynamic language and also a strongly typed language ,給出了 4 個答案,為 Python 的“動態強類型”定性:
再比如,在《流暢的Python》第11章的雜談中,也專門提到了強弱類型的分類。(它的用語是“很少隱式類型轉換”,算是比較嚴謹的,但是也錯誤地把 C++ 歸為了強類型。)
4、Python 是不是強類型語言?
關于“Python 是否屬于強類型”話題,在主流觀點之外,還存在著不少誤解的看法。
一方面的原因有些人混用了強弱類型與動靜類型,這有歷史的原因,前面已經分析了。
另外還有一個同樣重要的原因,即有人把弱類型等同于“完全沒有隱式類型轉換”了,這種想法并不對。
事實上,強弱類型的概念中包含著部分相對主義的含義,強類型語言中也可能有隱式類型轉換。
比如,Rust 語言為了實現“內存安全”的設計哲學,設計了很強大的類型系統,但是它里面也有隱式類型轉換(自動解引用)。
問題在于:怎么樣的隱式類型轉換是在合理范圍內的?以及,某些表面的隱式類型轉換,是否真的是隱式類型轉換?
回到 Python 的例子,我們可以分析幾種典型的用法。
比如,"test"*3這種字符串“乘法”運算,雖然是兩種類型的操作,但是并不涉及隱式類型轉換轉化。
比如,x=10; x="test"先后給一個變量不同類型的賦值,表面上看 x 的類型變化了,用 type(x) 可以判斷出不同,但是,Python 中的類型是跟值綁定的(右值綁定),并不是跟變量綁定的。
變量 x 準確地說只是變量名,是綁定到實際變量上的一個標簽,它沒有類型。type(x) 判斷出的并不是 x 本身的類型,而是 x 指向的對象的類型,就像內置函數 id(x) 算出的也不是 x 本身的地址,而是實際的對象的地址。
比如,1 + True這種數字與布爾類型的加法運算,也沒有發生隱式類型轉換。因為 Python 中的布爾類型其實是整型的子類,是同一種類型!(如果有疑問,可查閱 PEP-285)
再比如,整數/布爾值與浮點數相加,在 Python 中也不需要作顯式類型轉換。但是,它的實現過程其實是用了數字的__add__()方法,Python 中一切皆對象,數字對象也有自己的方法。(其它語言可不一定)
也就是說,數字間的算術運算操作,其實是一個函數調用的過程,跟其它語言中的算術運算有著本質的區別。
另外,不同的數字類型雖然在計算機存儲層面有很大差異,但在人類眼中,它們是同一種類型(寬泛地分),所以就算發生了隱式類型轉換,在邏輯上也是可以接受的。
最后,還有一個例子,即 Python 在 if/while 之后的真值判斷,我之前分析過它的實現原理,它會把其它類型的對象轉化成布爾類型的值。
但是,它實際上也只是函數調用的結果(__bool__() 和 __len__()),是通過計算而得出的合理結果,并不屬于隱式的強制類型轉換,不在 untrapped errors 的范疇里。
所以,嚴格來說,前面 5 個例子中都沒有發生類型轉換。 浮點數和真值判斷的例子,直觀上看是發生了類型轉換,但它們其實是 Python 的特性,是可控的、符合預期的、并沒有對原有類型造成破壞。
退一步講,若放寬“隱式類型轉換”的含義,認為后兩個例子發生了隱式類型轉換,但是,它們是通過嚴謹的函數調用過程實現的,也不會出現 forbidden errors,所以還是屬于強檢查類型。
5、其它相關的問題前文對概念的含義以及 Python 中的表現,作了細致的分析。接下來,為了邏輯與話題的完整性,我們還需要回答幾個小問題:
(1)能否以“隱式類型轉換”作為強弱類型的分類依據?
明確的分類定義應該以《Type Systems》為準,它有一套針對不同 error 的分類,強弱類型其實是對于 forbidden errors 的處理分類。隱式類型轉換是其明顯的特征,但并不是全部,也不是唯一的判斷依據。
本文為了方便理解,使用這個主要特征來劃分強弱類型,但是要強調,強類型不是沒有隱式類型轉換,而是可能有很少且合理的隱式類型轉換。
(2)假如有其它解釋器令 Python 支持廣泛的隱式類型轉換,那 Python 還是強類型語言么?
語言的標準規范就像是法律,而解釋器是執法者。如果有錯誤的執法解釋,那法律還是那個法律,應該改掉錯誤的執法行為;如果是法律本身有問題(造成了解釋歧義和矛盾,或者該廢棄),那就應該修改法律,保證它的確定性(要么是強類型,要么是弱類型)。
(3)為什么說 Javascript 是弱類型?
因為它的隱式類型轉換非常多、非常復雜、非常過分!比如,Javascript 中123 + null結果為 123,123 + {}結果為字符串“123[object Object]”。
另外,它的雙等號“==”除了有基本的比較操作,還可能發生多重的隱式類型轉換,例如true==['2']判斷出的結果為 false,而true==['1']的結果是 true,還有[]==![]和[undefined]==false的結果都為 true……
(4)C++ 是不是弱類型語言?
前文提到《流暢的Python》中將 C++ 歸為強類型,但實際上它應該被歸為弱類型。C++ 的類型轉換是個非常復雜的話題,@櫻雨樓 小姐姐曾寫過一個系列文章做了系統論述,文章地址:如何攻克 C++ 中復雜的類型轉換?、詳解 C++ 的隱式類型轉換與函數重載!、誰說 C++ 的強制類型轉換很難懂?
6、小結強弱類型概念在網上有比較多的爭議,不僅在 Python 是如此,在 C/C++ 之類的語言更甚。
其實在學術上,這個概念早已有明確的定義,而且事實上也被很多人所接納。
那些反對的聲音大多是因為概念混用,因為他們忽略了另一種對語言進行分類的維度;同時,還有一部分值得注意的原因,即不能認為強類型等于“完全無隱式類型轉換”或“只要沒有xxx隱式類型轉換”。
到此,相信大家對“Python是強類型語言還是弱類型語言”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。