Commutativity in Python: When a == b ≠ b == a

The Equality Checks You Know

Take a look at how Python handles equality for simple built-in types.

x, y = 10, 3

print(
    f'{x == y = }',
    f'{y == x = }',
    sep='\n',
)

x == y = False
y == x = False

Here, when we compare the integers x and y using ==, Python correctly evaluates both x == y and y == x as False. This is consistent with the commutative property of equality.

Now, let’s see what happens when we use equality with strings.

x, y = 'abc', 'def'

print(
    f'{x == y = }',
    f'{y == x = }',
    sep='\n',
)

x == y = False
y == x = False

As we expect, x == y and y == x both return False, demonstrating that string comparison behaves commutatively as well.

But what happens when we start using custom objects and define our own equality behavior? Let's look at a class that implements __eq__ to control how equality is determined.

from dataclasses import dataclass

@dataclass
class T:
    value: int

    def __eq__(self, other):
        return self.value == other.value
print(
    f'{T(10) == T(10) = }',
    f'{T(20) == T(10) = }',
    f'{T(10) == T(20) = }',
    sep='\n',
)

T(10) == T(10) = True
T(20) == T(10) = False
T(10) == T(20) = False

In this case, we've defined a custom __eq__ method for the class T, which compares the value attribute of instances. Notice that T(10) == T(10) returns True, and both T(20) == T(10) and T(10) == T(10) returns False. Here, equality behaves as expected—it's commutative, meaning we can re-order our operands and obtain a consistent result.

Under the Hood

However, things get more interesting when we change the behavior of __eq__ in a subclass. Let’s override __eq__ in a derived class to see if equality can still be commutative.

from functools import wraps

def log(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        print(f'{func.__qualname__}{args!r}')
        return func(*args, **kwargs)
    return wrapper

@dataclass
class Base:
    @log
    def __eq__(self, other):
        return False

@dataclass
class Derived(Base):
    @log
    def __eq__(self, other):
        return True

class Unrelated:
    @log
    def __eq__(self, other):
        return True

base      = Base()
derived   = Derived()
unrelated = Unrelated()

Here, the base class Base has a __eq__ method that always returns False. The Derived class, however, overrides __eq__ to always return True. And finally, we have a completely Unrelated class whose __eq__ method always returns True Let’s see how this affects equality comparisons.

base == unrelated

Base.__eq__(Base(), <__main__.Unrelated object at 0x772bd7555e20>)

False

unrelated == base

Unrelated.__eq__(<__main__.Unrelated object at 0x772bd7555e20>, Base())

True

base == 1   # left.__eq__(right)

Base.__eq__(Base(), 1)

False

1 == base   # right.__eq__(left) ??

Base.__eq__(Base(), 1)

False

(1).__eq__(base)

NotImplemented

derived == base # left.__eq__(right)

Derived.__eq__(Derived(), Base())

True

base == derived # right.__eq__(left) ??

Derived.__eq__(Derived(), Base())

True

@dataclass
class T:
    @log
    def __eq__(self, other):
        return NotImplemented

@dataclass
class G:
    @log
    def __eq__(self, other):
        return NotImplemented

T() == G() # you can see that we attempt both calls!

T.__eq__(T(), G())
G.__eq__(G(), T())

False

Real Application Problem

So what does this have to do with Modin and pandas? This entire blog post was written because of a curious bug in modin that arose because of the comparison precedence above that breaks that commutative property.

As it turns out, one needs to be extra careful when creating these equality methods especially when they can be compared against any arbitrary object that your user passes in. In this case, the guidance is to always put the object that you have written an __eq__ method on the left side of the comparator to ensure that the logic you control is executed first, only falling back to the other objects __eq__ method if you return NotImplemented.

To demonstrate where this can be problematic, you may be familiar with the idea of array broadcasting:

import pandas as pd

s = pd.Series([1, 2, 3])
s == 'a'

0    False
1    False
2    False
dtype: bool

'a' == s

0    False
1    False
2    False
dtype: bool

This works great when comparing against built-in types—and we all know why this works now. But what about all of the other objects in pandas?

What if we had some number of columns which had a data type that is a defined instance of a pandas.CategoricalDtype and wanted to identify each of those columns.

import pandas as pd

dtype = pd.CategoricalDtype(categories=['a', 'b', 'c'])
df = pd.DataFrame({
    'col1': [*'abac'],
    'col2': [*'xyxz'],
    'col3': [1,2,3,4]
}).astype({'col1': dtype, 'col2': 'category'})

display(
    df,
    df.dtypes
)

col1    category
col2    category
col3       int64
dtype: object

To find each of the columns that have a 'category' dtype, we can do the following:

df.dtypes == 'category'

col1     True
col2     True
col3    False
dtype: bool

This is commutative because 'category' is a string and returns NotImplemented if the type comparison fails.

'category' == df.dtypes

col1     True
col2     True
col3    False
dtype: bool

But what if we wanted to find not ANY categorical datatype, but the specific one we defined in the dtype variable?

df.dtypes == dtype

col1     True
col2    False
col3    False
dtype: bool

The above clearly works, but can we flip the operands?

dtype == df.dtypes

False

Unfortunately not. We’ve broken the commutative property here and have stumbled onto some possibly surprising behavior (at least it surprised me). This means that if you ever perform this type of comparison, then the ordering of your operands is incredibly important. And, if you have an object whose logic should be prioritized, then you will need to be careful that your object is always on the left-hand side of the == operator.

Wrap-Up: Equality in Python Isn't Always Equal

At first glance, == in Python might seem straightforward—just a simple check to see if two things are "equivalent." But as we've seen, Python's data model adds nuance to this operation. The __eq__ method allows objects to define their own rules for equality, and when left and right operands are of different types, Python tries both directions before giving up.

So, the next time you see a == b, remember: Python isn't just checking if they're equal—it’s letting a or both the a and b objects weigh in on the decision. And sometimes, what looks like a simple comparison is actually a small negotiation between two types—that don’t always agree with one another.

Have you seen other strange bugs in Python? Join the DUTC Discord server and chat with experts and network with other Python users.