Is there a difference between
==
andis
in Python?
Yes, they have a very important difference.
==
: check for equality - the semantics are that equivalent objects (that aren't necessarily the same object) will test as equal. As the documentation says:
The operators <, >, ==, >=, <=, and != compare the values of two objects.
is
: check for identity - the semantics are that the object (as held in memory) is the object. Again, the documentation says:
The operators
is
andis not
test for object identity:x is y
is true if and only ifx
andy
are the same object. Object identity is determined using theid()
function.x is not y
yields the inverse truth value.
Thus, the check for identity is the same as checking for the equality of the IDs of the objects. That is,
a is b
is the same as:
id(a) == id(b)
where id
is the builtin function that returns an integer that "is guaranteed to be unique among simultaneously existing objects" (see help(id)
) and where a
and b
are any arbitrary objects.
You should use these comparisons for their semantics. Use is
to check identity and ==
to check equality.
So in general, we use is
to check for identity. This is usually useful when we are checking for an object that should only exist once in memory, referred to as a "singleton" in the documentation.
Use cases for is
include:
None
Usual use cases for ==
include:
The general use case, again, for ==
, is the object you want may not be the same object, instead it may be an equivalent one
PEP 8, the official Python style guide for the standard library also mentions two use-cases for is
:
Comparisons to singletons like
None
should always be done withis
oris not
, never the equality operators.Also, beware of writing
if x
when you really meanif x is not None
-- e.g. when testing whether a variable or argument that defaults toNone
was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!
If is
is true, equality can usually be inferred - logically, if an object is itself, then it should test as equivalent to itself.
In most cases this logic is true, but it relies on the implementation of the __eq__
special method. As the docs say,
The default behavior for equality comparison (
==
and!=
) is based on the identity of the objects. Hence, equality comparison of instances with the same identity results in equality, and equality comparison of instances with different identities results in inequality. A motivation for this default behavior is the desire that all objects should be reflexive (i.e. x is y implies x == y).
and in the interests of consistency, recommends:
Equality comparison should be reflexive. In other words, identical objects should compare equal:
x is y
impliesx == y
We can see that this is the default behavior for custom objects:
>>> class Object(object): pass
>>> obj = Object()
>>> obj2 = Object()
>>> obj == obj, obj is obj
(True, True)
>>> obj == obj2, obj is obj2
(False, False)
The contrapositive is also usually true - if somethings test as not equal, you can usually infer that they are not the same object.
Since tests for equality can be customized, this inference does not always hold true for all types.
A notable exception is nan
- it always tests as not equal to itself:
>>> nan = float('nan')
>>> nan
nan
>>> nan is nan
True
>>> nan == nan # !!!!!
False
Checking for identity can be much a much quicker check than checking for equality (which might require recursively checking members).
But it cannot be substituted for equality where you may find more than one object as equivalent.
Note that comparing equality of lists and tuples will assume that identity of objects are equal (because this is a fast check). This can create contradictions if the logic is inconsistent - as it is for nan
:
>>> [nan] == [nan]
True
>>> (nan,) == (nan,)
True
The question is attempting to use is
to compare integers. You shouldn't assume that an instance of an integer is the same instance as one obtained by another reference. This story explains why.
A commenter had code that relied on the fact that small integers (-5 to 256 inclusive) are singletons in Python, instead of checking for equality.
Wow, this can lead to some insidious bugs. I had some code that checked if a is b, which worked as I wanted because a and b are typically small numbers. The bug only happened today, after six months in production, because a and b were finally large enough to not be cached. – gwg
It worked in development. It may have passed some unittests.
And it worked in production - until the code checked for an integer larger than 256, at which point it failed in production.
This is a production failure that could have been caught in code review or possibly with a style-checker.
Let me emphasize: do not use is
to compare integers.