2010-03-05 79 views
33

在Python 2.6.4:爲什麼在Python中'> 0 True?

>> ''>0 
True 

這是爲什麼?

+21

順便說一句,Python 3.0產生一個'TypeError:unorderable types:str()> int()'進行相同的比較 – mjv 2010-03-05 02:01:30

+0

相關http://stackoverflow.com/questions/18387938/how-do-python-比較運算符和工作函數名稱作爲歌劇 – Kasramvd 2015-06-02 07:24:53

回答

71

允許任意對象的訂單比較原始的設計意圖是允許不同種類的名單排序 - 有效,這將使所有字符串旁邊按字母順序排列對方,所有數字以數字順序緊挨着,儘管兩個模塊中的哪一個先出現並不能保證該語言。例如,這允許在O(N log N)最壞情況下獲得任何列表中的唯一項目(即使是不可哈希項目中的唯一項目)

多年來,這種務實安排受到侵蝕。第一個問題出現在幾個版本之前,訂購比較複數的能力被拿走了。突然間,排序任何列表的能力消失:如果列表中包含複數,可能與其他類型的項一起使用,它不再適用。然後,Guido開始更加不喜歡異類列表,因此開始認爲它不是真的問題如果這樣的列表可以被有效地排序或者不是......因爲根據他的新思維,這樣的列表不應該首先存在。他沒有做任何事情來禁止他們,但也不願意接受任何妥協來支持他們。

注意,這兩個變化在Python的禪的「實用性節拍純潔」項目(這是早期寫的,移動的平衡一點點退後,當複數仍然可能是訂單相比;-) –更純潔一點,實用性稍差。然而,對於兩個任意對象進行排序比較(只要這兩個對象都不是複數;-),他們仍然保持很長時間,因爲在同一時間,Guido開始真正堅持保持強大的向後兼容性均爲實際純;-)。

所以,只有在Python 3中,它明確而有意地去掉了強大的向後兼容性約束,以允許一些長期需求但向後不兼容的增強(特別是簡化和去除過時的冗餘方式來執行某些任務),不同類型實例的順序比較成爲錯誤。

因此,這個歷史和哲學論文基本上是真正迴應你的「爲什麼」問題的唯一途徑......! :-)

+1

應該補充的是,雖然語言可能不再具有此功能,但任意列表的排序很容易被自定義比較器壓低。只需自己寫,以備需要時使用 - 也是一種非常實用的方法。 – Trilarion 2015-06-02 08:07:10

+0

注意:在Python 2中,一個複數可以與任何其他對象進行比較,除了另一個複數! 'complex(1,0)>'abc''是'False'但是'complex(1,0)> complex(0,0)'會產生一個'TypeError' – 2017-01-22 18:52:05

21

https://docs.python.org/2.7/tutorial/datastructures.html#id1

Note that comparing objects of different types is legal. The outcome is deterministic but arbitrary: the types are ordered by their name. Thus, a list is always smaller than a string, a string is always smaller than a tuple, etc. [1] Mixed numeric types are compared according to their numeric value, so 0 equals 0.0, etc.

+6

奇怪。令人耳目一新的是,他們不再允許Python 3.0 – 2010-03-05 02:52:46

相關問題