Почему сравнение "is" не используется вместо "==" для примитивных типов? - PullRequest
3 голосов
/ 22 мая 2019

Когда я использую 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" может быть опасным для примитивных типов. Сравнение с булевыми массивами numpy VS PEP8 E712

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

1 Ответ

4 голосов
/ 22 мая 2019

Python не имеет примитивных типов .Все в Python является объектом.

Как правило, единственное место, которое вы должны использовать is, - это гарантированные языком синглтоны, такие как True, False и None или, скажем, в целях отладки.вы действительно хотите проверить идентичность объекта.

В любом другом случае вы будете полагаться на подробности реализации и на специфические для реализации оптимизации, если вы используете is для обозначения равенства (например,Оптимизатор глазков и интернирование строк).Оператор равенства == и должен использоваться в этих случаях.Хотя интерпретатор Python часто оптимизирует неизменяемые типы, вы все равно не должны полагаться на идентичность, когда имеете в виду равенство, поскольку в большинстве случаев это не языковая гарантия .

В качестве примера, в то время как наВ CPython 3.7 вы можете "безопасно" испытать искушение выбрать is для сравнения маленьких целых чисел , поскольку они кэшируются, это подробности реализации , которые должны не полагаться.Это свободно изменить в 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 для "равноправных" сравнений, - это сравнение enum типов, которые гарантированно синглетонны:

import enum
class Color(enum.Enum):
    RED = 1
    BLUE = 2

RED = Color.RED
BLUE = Color.BLUE

print(Color(1) is RED)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...