Почему сравнение «is» не используется вместо «==» для примитивных типов?

Когда я использую 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

Если это просто соглашение, я бы подумал, что «есть» более разборчиво, чем «==», но я чувствую, что могут быть некоторые сумасшедшие пограничные случаи, когда может быть более одной копии примитивного типа.

Они могут быть неизменяемыми, но не уникальными, например. 1000 is 500 + 500 может и не быть True

Peter Wood 22.05.2019 00:50

Не могли бы вы привести пример? Потому что я только что попробовал это в консоли, и он возвращает True

Dave Liu 22.05.2019 00:51

Это говорит False для меня в Python 2.7 и Python 3.6.

Peter Wood 22.05.2019 00:52

@Peter Wood А, Python 3.7 возвращает True. Интересно.

Dave Liu 22.05.2019 21:45

Связано: stackoverflow.com/questions/132988/…

Dave Liu 23.05.2019 01:25
Почему в Python есть оператор "pass"?
Почему в Python есть оператор "pass"?
Оператор pass в Python - это простая концепция, которую могут быстро освоить даже новички без опыта программирования.
Некоторые методы, о которых вы не знали, что они существуют в Python
Некоторые методы, о которых вы не знали, что они существуют в Python
Python - самый известный и самый простой в изучении язык в наши дни. Имея широкий спектр применения в области машинного обучения, Data Science,...
Основы Python Часть I
Основы Python Часть I
Вы когда-нибудь задумывались, почему в программах на Python вы видите приведенный ниже код?
LeetCode - 1579. Удаление максимального числа ребер для сохранения полной проходимости графа
LeetCode - 1579. Удаление максимального числа ребер для сохранения полной проходимости графа
Алиса и Боб имеют неориентированный граф из n узлов и трех типов ребер:
Оптимизация кода с помощью тернарного оператора Python
Оптимизация кода с помощью тернарного оператора Python
И последнее, что мы хотели бы показать вам, прежде чем двигаться дальше, это
Советы по эффективной веб-разработке с помощью Python
Советы по эффективной веб-разработке с помощью Python
Как веб-разработчик, Python может стать мощным инструментом для создания эффективных и масштабируемых веб-приложений.
4
5
832
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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.

user2357112 supports Monica 22.05.2019 01:24

Другие вопросы по теме