Equality

Figuring out whether two things are the same or not might seem like it should be the easiest job in the world. Unfortunately that’s not the case. Equality, identity, and comparisons are surprisingly complicated topics in any programming language. Python is no exception.

We’ve talked some about this some before, but today we’ll see a few more situations where equality can be extremely subtle. The approaches to handling these subtleties, and the syntax we’ll use, are specific to Python. While they might present in different ways, these issues appear in any programming language, so let’s try not to get too bogged down in Python specifics!

Equality vs identity (on literals)

Python integers, strings, etc. that appear in our code “as themselves” are called literals. This is often the simple case, so let’s start there. If we assign two literal values to two identifiers:

a = 365
b = 365

Then, in our memory model, we’ve put the value 365 in memory at some location (call it loc 0), and the value 365 at another location (call it loc 1). Our program dictionary directs a to loc 0 and b to loc 1.

a and b are equal, according to the == operator:

>>> a == b
True

This operator, on integers, compares their literal values. But there’s at least one difference between a and b: the locations that they point to in memory. Python’s id function lets us inspect this.

>>> id(a)
140670548369360
>>> id(b)
140670547931312

There’s a fundamental operator in Python, is, that compares two expressions by the location that each occupies in memory. a is b will return True only when a and b have the same id.

>>> a == b
True
>>> a is b
False
>>> a is a
True

We often call == the equality operator, and is the identity operator. Equality is a function that takes two arguments and returns a boolean. Its implementation depends on what class the inputs belong to. Identity also takes two arguments and returns a boolean, but its implementation is always the same: check that the two locations in memory match.

We sometimes use the terminology:

• relational equality or structural equality for == (since the intent is that it reflect something about the internal structure of the values, and what matters about them); and
• referential equality or reference equality for is (since it’s about where the values live in memory—their references—and nothing else).

Checking identity is always very fast. Consider two strings, each 100,000 characters long, that differ only on the last character. Checking structural equality would involve comparing each corresponding pair of characters, and wouldn’t return False until after checking all 100,000 pairs. Checking identity, on the other hand, involves just one comparison of two memory locations: two numbers.

On the other hand, identity is a very precise thing to check. Most of the time we’re really interested in structural equality. E.g., do these two strings have the same characters in them, in the same order?

Subtleties with identity on literals

Let’s modify our example above just a bit and play with equality some.

>>> a = 255
>>> b = 255
>>> a == b
True
>>> a is b
True

What? Why is the behavior for 255 different from the behavior for 365 (which we just recently tried)? The answer is that when it runs your program, Python tries to be efficient.

Small integers are used more often in practice than large ones. (Here’s one of a few reasons: the size of initially-created lists is 0.) Python is designed to optimize certain kinds of computations by automatically loading the integers -5 to 256 into locations in memory. Assigning a = 255 points a to this pre-loaded location, and similarly for b, so a and b are referentially equal. This process is called interning. Python does something similar for strings; the details of which string literals get interned vary, depending on which version of Python you’re using and how you run your code.

You shouldn’t write code whose correctness depends on certain things being identical! Interning is a useful optimization, but not something you should assume.

There’s another thing that gets interned: None. Any two Nones should always be identical. This is something you can assume, that has real effects, as we’ll see in a minute!

Equality on classes

Let’s define a new class, with nothing special in it yet.

class Book:
    def __init__(self, author: str, title: str, edition: int):
        self.author  = author
        self.title   = title
        self.edition = edition

It’s natural to want to compare books. But how does relational equality work on our custom class?

>>> book1 = Book("Emily Bronte", "Wuthering Heights", 1)
>>> book2 = Book("Emily Bronte", "Wuthering Heights", 1)
>>> book1 is book2
False
>>> book1 == book2
False
>>> book1 == book1
True

We’ve created two different “copies” of Wuthering Heights and stored them at different locations in memory. It’s no surprise that they aren’t identical. But we never told Python how to compare books; it doesn’t know how to check equality, so it falls back to checking identity.

We need to add a class method to Book that computes this equality.

class Book:
    def __init__(self, author: str, title: str, edition: int):
        self.author  = author
        self.title   = title
        self.edition = edition

    def __eq__(self, other):
        return self.author  == other.author \ 
           and self.title   == other.title \
           and self.edition == other.edition

Evaluating book1 == book2 is exactly the same as evaluating book1.__eq__(book2).

Note: among other things, dataclasses will take care of the __eq__ method for us, defining it in the obvious way.

@dataclass
class Movie:
    title: str 
    director: str 

>>> Movie("Parasite", "Bong Joon-ho") == Movie("Parasite", "Bong Joon-ho")
True

Redefining equality

There’s another catch. What if I tried to do a comparison book1 == None? None doesn’t have an author field, so this will throw an exception. We could check in our __eq__ method that the objects we’re comparing have the same type:

    def __eq__(self, other):
        if isinstance(other, Book):
            return self.author  == other.author \ 
               and self.title   == other.title \
               and self.edition == other.edition
        else:
            return False

But since None is always interned, it’s often safer and more predictable to test identity: check for book1 is None instead of book1 == None. is will never crash, and will always behave correctly here.

You might find it surprising to change __eq__ in this way. But this is the power of relational equality: Python doesn’t enforce any rules about how we implement it—although it does give a set of guidelines that we must follow, like y==x implying that x==y. In some applications, we might want to consider two books to be equal regardless of whether their edition numbers match.

    def __eq__(self, other):
        if isinstance(other, Book):
            return self.author  == other.author \ 
               and self.title   == other.title 
        else:
            return False

>>> Book("Emily Bronte", "Wuthering Heights", 1) == Book("Emily Bronte", "Wuthering Heights", 2)
True

We’re even allowed to do something (very unsafe) like this:

import random

class IntWrapper:
    def __init__(self, val):
        self.val = val

    def __lt__(self, other):
        return self.val < other.val 

    def __gt__(self, other):
        return self.val > other.val 

    def __eq__(self, other):
        return random.randint(0, 1) == 0 

    def __repr__(self):
        return repr(self.val)

iw = IntWrapper(5)

>>> iw == iw
False
>>> iw == iw
True
>>> iw == iw
True
>>> iw == iw
False
>>> iw == iw
True

Think about how much this would break! Lots of things depend on a “sensible” implementation of __eq__. So, let’s be more precise about that word: “sensible”. What must any sensible __eq__ implementation guarantee? Think about it!

Morals

Most programming languages have this same distinction between identity and equality. Depending on the language, it’s rare that you need to think about identity. But understanding the concept can help you debug confusing behavior, and with careful use, you can use it to write very efficient code.

Similarly, most languages give us a lot of freedom when it comes to defining equality. (In languages that don’t, we often see other complications.) But with this freedom comes the responsibility not to abuse it! Bad equivalences can be a huge source of bugs.

In languages beyond Python…

Different languages sometimes have additional notions of equality. Javascript, for example, has == and === (three = symbols!) operators.

We don’t use JavaScript in this class, but to motivate what I’m saying, here’s an example. I ran this via node on my Machine, after installing node.js; if you also install it, ignore their advertisement banner and just click to install 20.10.0 (long term support).

Like Python, JavaScript will implicitly convert types:

> 1 + 1.1
2.1
> 1 + '1' 
'11'

But it does this even more subtly than Python. Notice that this produces a value, not an error:

> 1 / 0
Infinity

Equality works like you might expect for such a language:

> 1 == '1' 
true

But what if you want to know that two things are equal, without implicitly converting types? (Note that this is NOT THE SAME as referential vs. structural equality; it’s a different dimension entirely.)

If you want to sidestep the automatic type conversion in JavaScript, you use ===:

> 1 === '1'
false

But notice that even == may not work like you’d expect:

> [1,2,3] == ['1', '2', '3']
false

Python also returns False for the above, but that’s more understandable because Python also returns False for 1 == '1'. In contrast, JavaScript considers 1 to be == to '1'. So why is JavaScript doing this?

Put another way, what’s an experiment you’d like to try to help understand this phenomenon?

> [1,2,3] == [1,2,3]
false

> {} == {}
false