Introduction

Yes. In Python, == checks whether two objects are equal in value, while is checks whether two references point to the exact same object. They answer different questions, and confusing them creates subtle bugs that sometimes appear only after a small refactor.

Equality and Identity Are Different Concepts

Use == when you care about value. Use is when you care about object identity.

1a = [1, 2, 3]
2b = [1, 2, 3]
3c = a
4
5print(a == b)
6print(a is b)
7print(a is c)

The result shows the difference clearly:

• 'a == b is True because the two lists contain the same values'
• 'a is b is False because they are different objects'
• 'a is c is True because both names point to the same list object'

That distinction is the core rule to remember.

Why is Sometimes Appears to Work for Values

Python may reuse certain objects internally, especially small integers and some short strings. Because of that, is can appear to “work” in small experiments.

1x = 256
2y = 256
3print(x is y)
4
5p = int("1000")
6q = int("1000")
7print(p == q)
8print(p is q)

This can trick people into thinking is is a faster or more direct equality test. It is not. Any apparent success here depends on implementation details such as interning and object reuse, not on the meaning of the operator.

The Correct Everyday Use of is

The most important normal use of is is with singleton values such as None.

1def normalize_name(name):
2    if name is None:
3        return "unknown"
4    return name.strip()

is None is preferred because it checks identity against a true singleton and does not depend on user-defined equality behavior.

Another legitimate use is a sentinel object:

1MISSING = object()
2
3
4def get_option(config, key):
5    value = config.get(key, MISSING)
6    if value is MISSING:
7        return "default"
8    return value

Here identity is the entire point. The sentinel should be unique.

== Depends on the Type’s Equality Rules

For user-defined classes, == depends on how equality is implemented. Dataclasses are a good example because they make value comparison explicit.

1from dataclasses import dataclass
2
3@dataclass(frozen=True)
4class Point:
5    x: int
6    y: int
7
8p1 = Point(2, 3)
9p2 = Point(2, 3)
10
11print(p1 == p2)
12print(p1 is p2)

These two objects are equal in value but not identical in memory. That is usually the behavior you want for domain data.

A Good Team Rule

A simple and reliable rule is:

• use == for normal data comparison
• use is for None, explicit sentinels, and rare identity-sensitive cases

That rule prevents most bugs and makes code review easier because unexpected uses of is stand out immediately.

Debugging Mistakes Around Identity

A lot of confusion starts when two printed values look identical and developers assume they must be the same object. They do not have to be.

The reverse mistake also happens: two variables unexpectedly change together because they reference the same mutable object, and the bug gets misdiagnosed as an equality problem when it is really an identity and aliasing problem.

Understanding both == and is helps with both categories of bugs.

Common Pitfalls

The most common mistake is using is for strings, integers, or tuples because it seemed to work in a quick test.

Another pitfall is writing == None when is None is clearer and more precise. Developers also sometimes forget to define meaningful equality for custom classes and then get surprising False results from == because the default identity-based object comparison is still in effect.

Finally, do not rely on interning behavior for correctness. That is not what is is for.

Summary

• '== compares values.'
• 'is compares object identity.'
• Use == for ordinary application data.
• Use is mainly for None and explicit sentinels.
• Never rely on object interning behavior to make is behave like equality.