Introduction

Yes, there is a real difference between foo is None and foo == None. The first checks identity, while the second checks equality.

In Python, None is a singleton, so the idiomatic and correct test is is None. This is not only about style. It avoids custom equality behavior and communicates your intent precisely.

Identity and Equality Are Different Operations

The is operator checks whether two names refer to the exact same object in memory. The == operator checks whether two objects should be considered equal according to their equality rules.

For ordinary values, equality is usually what you want:

print([1, 2] == [1, 2])  # True
print([1, 2] is [1, 2])  # False

Those two lists have the same contents, so they are equal, but they are not the same object.

For None, identity is the right question because there is only one None object:

1value = None
2
3print(value is None)   # True
4print(value == None)   # Also True here, but not preferred

Why == None Can Be Wrong

Equality can be overloaded through __eq__. That means an object can claim to be equal to None even when it is not actually None.

1class Strange:
2    def __eq__(self, other):
3        return other is None
4
5
6value = Strange()
7
8print(value == None)   # True
9print(value is None)   # False

This example is intentionally odd, but it demonstrates the risk clearly. == None can run arbitrary application code. is None cannot.

That is the real reason Python style guides recommend identity checks for None.

The Idiomatic Form

PEP 8 recommends:

• 'if value is None:'
• 'if value is not None:'

That style is both explicit and safe:

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

The intent is obvious: this branch is about the absence of a value, not about general equality.

Linters reinforce this rule because it prevents subtle bugs and makes code reviews easier. When another Python developer sees is None, they immediately know the code is testing for the singleton object itself rather than relying on a custom equality definition.

Do Not Confuse None With Falsy Values

Another common mistake is replacing a None check with a truthiness check.

1value = 0
2
3print(value is None)  # False
4print(not value)      # True

These mean different things. not value matches empty strings, empty containers, 0, False, and None. Use it only when you intentionally want that broader behavior.

If you specifically need to know whether a variable is missing rather than merely falsy, use is None.

This shows up often in function arguments. An empty list may be a valid value, while None may mean "the caller did not supply anything." Those two cases should not be collapsed into the same condition accidentally.

Common Pitfalls

• Writing == None out of habit from other languages.
• Using if not value when the code should only treat None as missing.
• Using is for ordinary value equality checks where == is the correct operator.
• Assuming == None is harmless just because it often works with built-in types.

Summary

• 'is None checks identity and is the correct way to test for None.'
• '== None checks equality and can trigger custom __eq__ logic.'
• 'None is a singleton, which is why identity is the right semantic check.'
• Do not replace a None check with a generic falsy check unless that is truly what you want.
• Use is not None for the inverse condition.