При сравнении кортежа со списком как...
>>> [1,2,3] == (1,2,3)
False
>>> [1,2,3].__eq__((1,2,3))
NotImplemented
>>> (1,2,3).__eq__([1,2,3])
NotImplemented
... Python не делает глубоко - сравнивают их, как покончили (1,2,3) == (1,2,3)
.
Таким образом, какова причина этого? Это, потому что изменяемый список может быть изменен когда-либо (проблемы потокобезопасности) или что?
(Я знаю, где это реализовано в CPython, поэтому не отвечайте, где, но почему он реализован.)
Вы всегда можете "преобразовать" его
>>> tuple([1, 2]) == (1, 2)
True
Имейте в виду, что Python, в отличие, например, от Javascript, строго типизирован , и некоторые (большинство?) из нас предпочитают именно так.
Нет никаких технических причин, по которым списки не могут сравниваться с кортежами; это полностью дизайнерское решение, основанное на семантике. Для доказательства того, что это не связано с безопасностью потоков, вы можете сравнить списки с другими списками:
>>> l1 = [1, 2, 3]
>>> l2 = [1, 2, 3]
>>> l1 == l2
True
>>> id(l1) == id(l2)
False
Кажется разумным разрешить пользователям напрямую сравнивать списки и кортежи, но тогда у вас возникают другие вопросы: следует ли пользователю разрешать сравнивать списки и очереди? А как насчет любых двух объектов, которые предоставляют итераторы? А как насчет следующего?
>>> s = set([('x', 1), ('y', 2)])
>>> d = dict(s)
>>> s == d # This doesn't work
False
Это может очень быстро усложниться. Разработчики языка осознали проблему и избежали ее, просто не допустив прямого сравнения различных типов коллекций друг с другом 1 .
Обратите внимание, что простое решение (создать новый список из кортежа и сравнить их) легко, но неэффективно. Если вы работаете с большим количеством элементов, вам лучше использовать что-то вроде:
def compare_sequences(iter1, iter2):
iter1, iter2 = iter(iter1), iter(iter2)
for i1 in iter1:
try:
i2 = next(iter2)
except StopIteration:
return False
if i1 != i2:
return False
try:
i2 = next(iter2)
except StopIteration:
return True
return False
Это дает преимущество работы с любыми двумя последовательностями при очевидной цене за счет сложности.
1 Замечу, что есть исключение для наборов и фрозенсетов. И, без сомнения, некоторые другие, о которых я не знаю. Разработчики языка пуристы, за исключением тех случаев, когда практичность окупается.