is vs == in Python

Two lists with the same contents are equal but they are not identical. Equality asks whether two objects represent the same value. Identity asks whether two names refer to the very same object.

a = [1, 2]
b = [1, 2]

print(a == b)   # True, the contents are the same
print(a is b)   # False, they are two separate list objects


def describe(items):
    for item in items:
        if item is None:
            return 'missing value found'
    return 'nothing missing'


print(describe([1, None, 3]))   # missing value found

For the None test, is None is not only the recommended form, it is the only form that is guaranteed to work. None is a singleton, so there is exactly one None object in the whole process and every reference to it points at that same object. That is what makes is None an identity test that always behaves in the same way. Writing == None happens to work by accident, because the equality of None is identity, but it is fragile. It relies on an implementation detail, and it will mislead anybody who has just been told that == means value comparison.

The rule that makes this clean is short. Use == when you mean the same value, and use is when you mean the same object, with one single exception. A None check is an identity test by design, so is None is exactly right there.

A useful defensive habit is the negated form. Write if value is not None: rather than if value:, because the second one is also True for an empty string, a zero, and an empty list. Those are all perfectly valid values that simply happen to be falsy.

The is operator compares object identity. It asks whether both names are bound to the very same object. It does not look at the contents, and it never calls a method that you have written yourself.

# Two separately built values are equal but they are not identical.
first = int('1000')
second = int('1000')

print(first == second)   # True, the value is the same
print(first is second)   # False, they are two different int objects

text = 'hello'
other = ''.join(text)

print(text == other)     # True, the value is the same
print(text is other)     # False, a new string object was built

# The one case where identity is guaranteed.
print(None is None)      # True

The two int() calls each build a fresh integer, so first and second hold equal but separate objects. Equality says True and identity says False. The string case shows the same thing with a value that looks like a literal, because joining the characters builds a new string. It equals the original without being the original.

None is the exception that proves the rule. The interpreter creates exactly one None object, so any two references to it are the same object, and identity and equality agree with each other. That is the reason why is None is safe.

There is a related detail that is worth showing if an interviewer pushes a little further. CPython keeps small integers in a cache, so two separately written 200 values in the same module often turn out to be the very same object. That behaviour is an implementation detail of the interpreter, and it is exactly why you should never write code that depends on it.

Because identity is not part of the way the language describes values, any code that depends on it is depending on an implementation detail that can change without any warning. CPython happens to keep small integers in a cache. The range from -5 to 256 is created when the interpreter starts, so every 200 in your program is the same object. Beyond that range, each separately calculated integer is a new object. A string literal inside the same code object may share an object with an identical literal, but a string that is built while the program runs will not.

So code like if value is 1000 can pass in your tests, because the small-integer cache made it true, and then fail in production, because the value arrived from a network request or from a database and was worked out at run time. The same thing applies to string literals that are compared with is. Two writes of the same literal in one module may share an object, while the same text built by two different code paths will not.

The cache is also an optimisation and not a contract. The guarantee that is actually documented is narrow. The small integer range is cached so that arithmetic on small integers does not have to allocate anything. Nothing in the language specification promises that 1000 is cached, and other interpreters are free to behave differently.

The rule to state in an interview is simple. Use == for value comparison of numbers, strings, and collections. Use is only for identity, and in practice that means exactly two things. Check against None with is None, and check against a sentinel object that you created yourself. For a module-level sentinel you compare with is, because you deliberately want the same object, and that pattern is genuinely correct.