因此,首先,你會發現,你不能字符串列表上執行sum
將它們串聯,蟒蛇告訴你使用str.join
取而代之,這是很好的建議,因爲無論你如何在字符串上使用+
,性能都很糟糕。
「不能使用sum
」限制不適用於list
,儘管itertools.chain.from_iterable
是執行此類列表展平的首選方式。
但sum(x,[])
當x
是列表的列表是肯定不好的。
但是它應該保持那種方式嗎?
我比3接近
import time
import itertools
a = [list(range(1,1000)) for _ in range(1000)]
start=time.time()
sum(a,[])
print(time.time()-start)
start=time.time()
list(itertools.chain.from_iterable(a))
print(time.time()-start)
start=time.time()
z=[]
for s in a:
z += s
print(time.time()-start)
結果:列出的名單上
sum()
:10.46647310256958。好的,我們知道。itertools.chain
:0.07705187797546387- 使用自定義的積累和就地另外:0.057044029235839844(可快於
itertools.chain
正如你看到的)
所以sum
是遠遠落後,因爲它執行的result = result + b
代替result += b
所以,現在我的問題:
爲什麼不能sum
可用時,這種累積方法可用樂?
(這將是透明的,已經存在的應用程序和將使得有可能使用的sum
內置扁平化高效名單)
也許可以調整它以檢查'empty'是否爲空,並且在這種情況下使用另一個空列表(或者如果不是太大,則創建一個副本)。這將是透明的,不會花費大量的CPU(複製評論對另一個答覆者) –
語言設計是非常微妙的。棘手的調整可能會導致其他意想不到的行爲。如果人們習慣於使用* sum()*作爲非數字工作,那麼他們更有可能陷入與其他類型的二次行爲中,例如'sum(list_of_tuples,())'或'sum( list_of_sets,set())''。即使這些是高性能的,仍然存在一些問題,即* sum *這個詞是否是表達* concatenate *或* set.union *或「flatten」的業務邏輯概念的最明確方式。 Guido的設計本能有着出色的記錄。對BDFL進行第二次猜測是危險的;-) –
這是一個很好的觀點。在這種情況下,爲什麼我們不能阻止像sum這樣巧妙地使用字符串的情況?也許在Python 4? –