The Storeroom

An appendix to my favourite Python programming analogy—The White Room analogy

Dec 17, 2024

You may know I like analogies. And if you've been reading this publication long enough, or if you read The Python Coding Book, you'd be familiar with Monty and The White Room. If not, then where have you been all this time?

Don't despair. I'll give you the briefest of summaries and links to all three parts of the analogy soon.

But analogies aren't perfect. Every analogy breaks down if you dig deep enough. I'm currently writing the chapter on analogies in my upcoming book on narrative technical writing, Breaking the Rules, and one of the examples I use of an analogy breaking down is The White Room—not even my favourite analogy is spared!

I've been using this analogy in my Python teaching for many years, and I've had students find this particular breaking point often. And that's a good thing. Finding an analogy's breaking point or limitation is a sign you understand the topic. So, I always have a sense of pride when a student identifies this flaw and asks about it. It means they got it!

But I have a fix. I can modify and extend the analogy to keep it going a bit further. I often discuss this solution in live courses when students ask, but I never wrote it down. Until now. I always felt that you don't need to take an analogy beyond its breaking point. But then, this fix is quite good, if I may say so myself. So, I thought it was high time I wrote it and shared it with you.

I'll present things in a jumbled order in this article.

First, I'll tell you about the flaw in the analogy.

Then, I'll briefly summarise the main analogy since the flaw and its solution make more sense if you actually know what The White Room analogy says! I'll provide links for further reading, of course.

And finally, I'll present the fix to the flaw, the patch that keeps the analogy going a bit longer…

A minute of your time. Thank you to all of you who read these articles. And thank you to the paid subscribers and those who contribute from time to time. As you can imagine, a lot of time and effort goes into these articles, all in the evenings and weekends.

If you want to contribute, you can upgrade to a paid subscription, either just for a few months ($5 per month) or using the yearly option ($50).

Alternatively, you can make a one-off contribution whenever you can, any amount you want.

Now, back to the article.

The Flaw in the Analogy

I developed The White Room analogy incrementally over many years of teaching. However, one part of the analogy is based on another well-known metaphor, the box analogy.

This simpler analogy says that a variable is a box that stores data. The name of the variable is the label on the box. The White Room analogy also uses boxes to represent variables.

At first sight, this works perfectly for Python. The name of the variable is not the object itself but a reference to the object. So, we can separate the name of the variable from the object by referring to the label on the box (the variable name) and the item inside the box (the Python object).

Brilliant.

But what if you have multiple references to the same object?

All code blocks are available in text format at the end of this article • #1 • *The code images used in this article are created using Snappify. [Affiliate link]*

In this example, there's only one string object. In the first line, you create the name title, which refers to the string object.

The second line doesn't create a copy of the string. Instead, it creates a second name—Python names are also known as identifiers—and links this new name, this_publication, to the same object.

One object. Two names referring to it.

So, how does this fit with the box analogy? You have two boxes but only one string object. Where do you put the object? In the first box? In the second?

It just doesn't work that way. The analogy breaks down.

But when students challenge me on this box analogy, it's often when dealing with lists or other data structures:

The string "Kenneth" is in the box labelled team_member. So, what's in the list? Is the string in there, too? But there's only one. Argh!

This is the same issue as in the first example. The box analogy fails for the same reason.

Reviewing the Story of Monty and The White Room

I won't explain The White Room analogy in full in this article. I wrote a three-part series here on The Python Coding Stack that goes through the analogy in detail (and an interlude chapter in The Python Coding Book is dedicated to this analogy). Here's a quick summary, but you can skip this section if you're familiar with Monty and The White Room:

Part 1: Monty and The White Room—Monty is an avatar that runs the computer program. He reads, understands, and executes the code you write. There's an empty room with white walls. It only has a set of shelves. This room is the infrastructure for the main program. When you create a variable, Monty uses a box, labels it using the variable name, and places the object in the box. He places the box on the shelves, and the next time you use the variable name, Monty finds this box and looks at its contents. When you import a module in your code, Monty fetches a book with instructions from a central library and places it on one of the shelves in the main room.
Part 2: The Function Room—When you define a function, Monty builds a new empty room adjacent to the main room. The door leading from the main room to the function room has a label. This label has the function name on it. When you call a function, Monty goes through this door, taking any objects he needs with him. He performs the task required in the function room, then returns to the main room, taking some objects back with him to the main room. This part of the analogy also deals with parameters and arguments.
Part 3: Python City—The main white room you create when you write a computer program exists within Python City, which is the Python ecosystem that's installed on your computer. You already read about the main library. This library in Python City contains "books" that represent modules and packages from the Python standard library and other third-party ones you install in your Python environment. There are also neighbourhoods with rooms and buildings relating to these modules and packages, such as the random neighbourhood.

If you're new to the analogy, do take the time to read through the three separate articles. The succinct summary in the bullet points above doesn't do the analogy justice!

Fixing the Flaw • The Storeroom

So, in the main analogy, Monty gets a box when you define a variable. He labels it using the variable name and places the object in the box.

But you saw earlier how this causes a problem. How can the same object be in multiple boxes when you create more references to it? Python uses the same object in these cases, not a copy.

So, here's the update.

Let's use this example again:

Monty creates a new string object. He also brings an empty box and sticks a label with title on it. But he doesn't put the string object in the box.

Instead, he takes the new string object he just created into an adjacent Storeroom. This storeroom has aisles with shelves. Each aisle, section, and shelf is labelled. Monty looks for an empty spot on these shelves in the storeroom. For example, Monty may place the new object in Aisle 4, Section D, Shelf 9.

Back in the main room, Monty gets a pen and a small slip of paper, writes "Aisle 4, Section D, Shelf 9", and places this slip of paper in the box labelled title. The box goes on the shelf in the main room, as it did in the original analogy.

We'll soon see what Monty does when he needs to fetch this object, but I'm sure you can already guess!

Let's get back to the code. Later in the code, you have the following line:

Monty starts from the right-hand side of the assignment operator, =. He reads the name title. Monty looks around the main white room, which hosts the main program, and he finds a box labelled title. He brings the box down from the shelf and looks inside.

He finds the slip of paper that tells him where to find the object he needs. He goes to the storeroom, finds aisle 4, walks to section D, and looks at the ninth shelf. There, he finds the object he needs, which is the string object "The Python Coding Stack".

The line of code Monty is working on is an assignment statement. Therefore, Monty doesn't really need to fetch the object in this case. But there may be expressions that require Monty to use the object, of course.

In this assignment, Monty gets a new blank slip of paper, writes the location of the object on the paper, and places it in a new box labelled this_publication in the main room. The object is still in the storeroom in aisle 4, section D, shelf 9.

Now, there are two separate boxes in the main room. One is labelled title and the other this_publication. Both contain a slip of paper showing Monty where he can find the object. In this case, the papers in the two boxes are identical—they contain the same storeroom location, the same address. Both boxes lead Monty to the same object.

And whenever a variable name is reused through an assignment, for example, Monty throws the old slip of paper in the trash and replaces it with a new one. For example, consider the following line of code:

Monty creates a new string object, finds a place for it in the storeroom, and writes the aisle, section, and shelf references on a piece of paper. Back in the main room, he notices there's already a box labelled this_publication. He removes the old slip of paper from the box. This paper has the address of the old string, The Python Coding Stack. Monty replaces it with the new one.

The old string is still in the storeroom. But Monty removed its reference from one of the boxes.

Perfection?

So, is The White Room analogy perfect now that we applied this patch? No. No analogy can ever be perfect. Dig further, go deeper, and it will fail. All analogies fail eventually. That doesn't mean they're not useful!

You can read more about my theory of analogies, along with lots more research, ideas, and thoughts about narrative technical writing, in Breaking the Rules*.

*to be published in the coming weeks

Code in this article uses Python 3.13

The code images used in this article are created using Snappify. [Affiliate link]

For more Python resources, you can also visit Real Python—you may even stumble on one of my own articles or courses there!

And you can find out more about me at stephengruppetta.com

Further reading related to this article’s topic:

Monty and The White Room (Part 1 of The White Room Analogy Series)
The Function Room (Part 2 of The White Room Analogy Series)
Python City (Part 3 of The White Room Analogy Series)
Not Python-related, but you may find my book on narrative technical writing interesting: Breaking the Rules

Appendix: Code Blocks

Code Block #1

title = "The Python Coding Stack"
this_publication = title

Code Block #2

team_member = "Kenneth"
team = [team_member, "John", "Kate", "Matilda"]

Code Block #3

title = "The Python Coding Stack"

Code Block #4

this_publication = title

Code Block #5

this_publication = "Breaking the Rules"