Когда я использую Pytest для форматирования Python, он жалуется на то, что делает что-то вроде:
>>> assert some_function_ret_val() == True
E712 comparison to True should be 'if cond is True:' or 'if cond:'
и хочет:
assert some_function_ret_val() is True
Я знаю, что может быть только одна копия True/False/None, но я думал, что все примитивы являются неизменяемыми типами.
При каких обстоятельствах сравнение "==" и "is" будет отличаться для примитивных типов??
Иначе почему "==" стало нормой в задачах сравнения?
Я нашел этот пост stackoverflow, в котором говорится о сравнении с непримитивными типами, но я не могу найти причину, по которой сравнение «есть» может быть опасным с примитивными типами. Сравнение с логическими массивами numpy VS PEP8 E712
Если это просто соглашение, я бы подумал, что «есть» более разборчиво, чем «==», но я чувствую, что могут быть некоторые сумасшедшие пограничные случаи, когда может быть более одной копии примитивного типа.
Не могли бы вы привести пример? Потому что я только что попробовал это в консоли, и он возвращает True
Это говорит False
для меня в Python 2.7 и Python 3.6.
@Peter Wood А, Python 3.7 возвращает True. Интересно.
Связано: stackoverflow.com/questions/132988/…
Python не имеет примитивных типов. Все в Python является объектом.
Как правило, единственное место, где вы должны использовать is
, — это гарантированные языком синглтоны, такие как True
, False
и None
, или, скажем, в целях отладки, когда вы действительно хотите проверить идентичность объекта.
В любом другом случае вы будете полагаться на детали реализации и оптимизации, специфичные для реализации, если используете is
для обозначения равенства (например, оптимизатор глазка и интернирование строк). В таких случаях следует использовать оператор равенства ==
. Хотя часто интерпретатор Python оптимизирует неизменяемые типы, вы все равно не должны полагаться на идентичность, когда имеете в виду равенство, потому что в большинстве случаев это не языковая гарантия.
Например, в CPython 3.7 у вас может возникнуть соблазн использовать "безопасно" для сравнения маленькие целые числа, потому что они кэшированы, это деталь реализации, на который следует полагаться на нет. Это можно изменить в Python 3.9 или когда угодно. Кроме того, см. комментарий пользователя @user2357112 о том, что это даже не обязательно безопасно для кэшированных небольших целых чисел! Повторюсь: это не языковая гарантия — это побочный эффект того, как он был реализован.
А также, опять же, это применимо только к небольшим целым числам, [-5, 256], поэтому:
>>> def add(a, b): return a + b
...
>>> 16 is add(8, 8)
True
>>> 1000 is add(500, 500)
False
Обратите внимание, что я помещаю фактическое дополнение в функцию, интерпретатор часто оптимизирует неизменяемые литералы и арифметические выражения:
>>> 1000 is (500 + 500)
True
Но теперь должно быть очевидно, почему вы не можете полагаться на это.
Другой пример, когда уместно использовать is
для «равноправных» сравнений, — это сравнение типов is
, которые являются гарантированными синглтонами:
import enum
class Color(enum.Enum):
RED = 1
BLUE = 2
RED = Color.RED
BLUE = Color.BLUE
print(Color(1) is RED)
Полагаться на небольшой целочисленный кеш даже небезопасно в текущем CPython, потому что он используется не для всех операций. Например, 3-аргумент pow
не всегда использует кеш, поэтому pow(5, 30, 5**30-1) == 1
, но pow(5, 30, 5**30-1) is not 1
.
Они могут быть неизменяемыми, но не уникальными, например.
1000 is 500 + 500
может и не бытьTrue