Introduction

In Python, the right way to test for None is usually is None, not == None. The difference is that is checks identity, while == checks equality and may call custom comparison logic.

None Is a Singleton

Python has exactly one None object. That is why identity comparison is the natural test.

1value = None
2
3if value is None:
4    print("No value")

This asks, "is this object the actual None singleton". That is precise and predictable.

== None Uses Equality Logic

When you write value == None, Python is not required to do a simple identity check. It may call value.__eq__(None), and user-defined classes can implement that however they want.

Here is a deliberately strange example:

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

Output:

True
False

That is the whole reason is None is preferred. Equality can lie for domain-specific reasons. Identity cannot.

Why is None Is the Idiomatic Choice

is None is recommended because:

• it matches Python's singleton model
• it avoids custom __eq__ surprises
• it communicates intent clearly

In real code, this often appears in function arguments:

1def load_user(user_id=None):
2    if user_id is None:
3        return "anonymous"
4    return f"user:{user_id}"
5
6
7print(load_user())
8print(load_user(42))

That is clearer than using a generic truthiness check such as if not user_id, which would also treat 0, False, and empty strings as missing.

is not None Is the Matching Form

When you want to assert presence, use is not None.

1result = 0
2
3if result is not None:
4    print("A value is present")

This matters when 0, False, or "" are legitimate values. A truthiness test would collapse those cases incorrectly.

Compare these two examples:

1result = 0
2
3if result:
4    print("truthy")
5else:
6    print("falsy")

1result = 0
2
3if result is not None:
4    print("not None")
5else:
6    print("missing")

The first example says nothing about missingness. The second one does.

When == None Shows Up Anyway

You may still see == None in old code or in generic equality discussions. It is not illegal Python, but it is usually the wrong comparison for ordinary application logic.

Linters and style guides generally push developers toward identity checks for None. The reason is not micro-optimization. The reason is correctness and clarity.

A Common Real Bug

Suppose a function returns either a count or None when data is unavailable:

1def get_count(name):
2    data = {"apples": 0, "oranges": 2}
3    return data.get(name)
4
5
6count = get_count("apples")
7
8if count is None:
9    print("missing")
10else:
11    print(f"count is {count}")

This prints count is 0, which is correct.

If you wrote if not count, you would incorrectly classify 0 as missing. That is why None checks should be explicit.

Common Pitfalls

• Using == None and accidentally invoking custom equality behavior.
• Using if not value when you specifically mean "missing" rather than "falsy".
• Forgetting the matching readable form is not None.
• Comparing to None in containers or frameworks that overload equality in surprising ways.
• Assuming the issue is performance. The bigger concern is semantic correctness.

Summary

• 'is None checks identity with the singleton None object.'
• '== None checks equality and can trigger custom __eq__ behavior.'
• For normal Python code, prefer is None and is not None.
• Use explicit None checks when 0, False, or empty strings are valid values.
• The main advantage of is None is correctness, not speed.