Monty and The White Room (Monty and The White Room Series #1)

Understanding a Python program through The White Room analogy • Part 1

Oct 08, 2023

It's been a long and busy day. But Monty is ready to go again. No, he's not tired. He never gets tired. And he never complains, either. He's just waiting for your signal.

Monty will do whatever you ask him to do. He's fast and efficient. Although he can be a bit silly at times, and take your instructions too literally. He never seems to understand the context of the problem he's solving. So make sure you give him clear instructions.

And there's one more thing. Monty doesn't understand English. No, not even German, Dutch, Mandarin, or Maltese. The only language he knows is Python.

You see, Monty is not a person. He's an avatar. He's the one who reads your instructions and gets things done when you run a computer program.

You can also watch videos on The Python Coding Place’s YouTube channel covering this analogy.

This article is the first in the Monty and The White Room series. In this short series, I'll explain how a computer program works. No mean feat, you may think! But don't expect to read the stuff you find in a computer science textbook.

This series will expose the truth that's been hidden from you all this time. Inside your computer, there's a whole city, Python City. And you already met Monty. He lives in Python City and keeps himself busy each time you run a computer program. This series will tell you his story.

Right, so perhaps there isn't an actual city inside your computer, and Monty may not be real after all. Who knows? But real or not, the White Room analogy that I'll describe in this series is my favourite programming analogy, and one which has helped me and many of my students grasp the fundamental programming concepts.

Overview of the 'Monty and The White Room' series

Part 1 (this article) • Monty and The White Room. The article introduces the analogy and its main character, Monty. It deals with the basic structure of a computer program, including importing modules, creating variables, and names. We also start to understand the concept of namespaces.
Part 2 • The Function Room. In Part 2, we extend the analogy to include defining and calling functions, including function arguments and return values. We also learn more about scope.
Part 3 • Python City. The series ends by zooming out from the "rooms" we're creating in our code base to look at how they're connected with other parts of the Python ecosystem.

I first introduced this analogy as an interlude chapter in The Python Coding Book: The White Room • Understanding Programming.

Introducing Monty and The White Room

The story starts in a medium-sized room. It's empty. The walls and ceiling are white. This stage of the analogy represents opening a new, empty .py file. Since I use a light theme on my IDE (and if you're sniggering there at the back, read this), this image is ideal—the white room is a three-dimensional representation of the white IDE screen.

But even before you write a single word in your script, the white room is not entirely empty. You see some shelves on one of the walls.

The shelves are bare except for the bottom one. There's a small, red booklet with the label "built-in" on it. It's the only thing in the room. We'll get back to this solitary item soon.

You also notice someone in one of the corners of the room. But it's not a person. It's a small, cartoon-like figure. This is Monty. He's ready to do whatever you ask him to do.

Giving Monty His First Task

You start writing code on the blank screen. Let's start with a simple task:

When you run this code, Monty springs into action. He starts reading the only line of code you wrote.

Monty reads the name print. He starts looking around the room. But there's nothing in the room—except the small, red booklet. And since he can't find anything labelled print elsewhere in the room, Monty picks up this red booklet and looks inside. And there it is, he finds print. He knows what to do. And the parentheses tell him he should do this now.*

Monty also recognises the quotation marks. They tell him the argument is a string.

*"He knows what to do. And the parentheses tell him he should do this now" is all I wrote here for now. You'll find out what really happens when Monty finds print in the red booklet in the second and third articles in Monty and The White Room series.

Let's add another line:

You've seen how Monty deals with the first line. So, let's focus on the second. Once he reads the name print, Monty looks for this name in the room, as he did earlier, and he'll find it in the red booklet.

Next, he reads the name today. The room is still empty, so Monty looks in the red booklet. But he doesn't find any references to the name today. Monty doesn't know what to do next. So he complains that he's stuck and doesn't know how to proceed:

 Traceback (most recent call last):
   ...
     print(today)
           ^^^^^
 NameError: name 'today' is not defined

Monty is not the most eloquent orator you'll ever meet. However, he's improved significantly in recent years, and he can express himself a lot better now when telling you what the problem is—error messages are much better in the latest versions of Python!

Adding Labelled Boxes

Monty couldn't find anything labelled today in the room. There was nothing on the shelves with that name. And there was no today entry in the red booklet. Monty calls this a NameError.

Let's assign a value to this name:

When Monty sees the line with the equals sign, he knows what to do:

Monty fetches an empty cardboard box.
He writes the name today on a label and sticks the label on the box.
He puts the string "Sunday" in this box.
Finally, Monty places the box on the shelves in the room, with the label clearly visible.

When Monty reaches the final line of code and reads the name today, he starts looking around the room for this name. But this time, he spots the label on the box, which he put there earlier. He brings the box down from the shelf and fetches its contents. So, Monty uses the string "Sunday" as argument for the print() function.

And each time Monty spots an equals sign, he fetches a new box, labels it using the name on the left-hand side of the equals sign, and stores whatever object is on the right-hand side of the equals sign in the box. He stores these boxes on the shelves.

But let's have a look at this scenario:

When Monty reaches the second assignment, the line that assigns "Monday" to the name today, he notices that there's already a box labelled today. Monty is the efficient type. He doesn't want to risk getting confused with two boxes with the same label. So he's got a rule he always follows: never use the same name twice.

So, on the second assignment to the name today. Monty first empties the box with the label today, which already exists. He discards its contents—the string "Sunday". Then, he puts the new object in that box—the string "Monday"—before placing the box back on the shelf.

And how about this?

When Monty reads the first line, he stores the string "Monday" in a box labelled today. When he reads the second line, though, he notices that the item on the right-hand side is the name of another box. So, he fetches a new label and writes start_of_week on this new label. Next, Monty places the label on the same box which already has the label today. He doesn't cover the old label. Instead, he places the new label next to it. The box containing the string "Monday" now has two labels instead of just one.

So, when Monty reads either today or start_of_week later in this program, he'll find the same box with the same item inside.

Fetching Books From the Central Library

Let's try the following code:

In the White Room analogy so far, we've focused on the room that represents the main program you created. But this room does not exist in isolation. We'll explore more rooms in the second and third articles in this series. But for today, we'll focus on just one more building. There is a large Central Library in the middle of Python City.

When Monty reads the first line in this code, import random, he knows what to do next. He leaves the room and goes for a stroll in Python City until he reaches the large building in the city centre, the Central Library.

In the library, he looks for a book named random, and once he finds it, Monty borrows this book out of the library and takes it back with him to the White Room. Back in the room, he places the book on one of the shelves with the spine facing out, clearly showing the book's name: random.

Later in the code, which in this case is on the next line, Monty reads the word random again. As with any other name he reads in the code, he looks around the room to see whether he can find anything with this name. He does. There's a book labelled random. He brings the book down from the shelf.

But when Monty read the name random, it was followed with .randint. So, he looks for the name randint within this book. And once he finds randint in the random book, he knows what to do.

This is the concept of namespaces. Monty won't be able to find the name randint on the shelves in the room. But he does find the book called random, and randint is within the book.

What's Next?

This brings us to the end of Part 1 in this three-part series. In this article, I set the scene for The White Room analogy. This room is the infrastructure in which a computer program runs. And Monty is the avatar that performs the actions in a computer program.

The white room is the namespace for our main program. So, Monty will look for any name you write in your program in this room. If the name refers to a variable name, Monty will find a box labelled with the variable name. If the name refers to a module you imported, Monty will find a book with that name, which he borrowed from the Central Library.

In part two of this series, we'll focus on functions and how this analogy represents defining and calling functions, including local variables, arguments, and return values.

The Analogy Caveat

I love analogies. I use them to understand things. And I use them often when teaching, too. I even wrote about using analogies in my other substack, Breaking the Rules, such as in this post: Whizzing Through Wormholes (Ep. 2).

But here's the analogy caveat: No analogy is perfect. If you dig deep enough, analogies will always break. The White Room analogy is robust, but it's still an analogy. You've been warned.

Ready for the second article in this series? Here you go: The Function Room.

Code in this article uses Python 3.12

Stop Stack

#33

Recently published articles on The Python Coding Stack:
- 5:30am • Timezone Headaches (Part 1) I need Python's help to figure out the time of my talk • Dealing with timezones and daylight saving with Python's zoneinfo and datetime modules • The first article in a two-part mini-series
- A Slicing Story Are you sure you know everything there is to know about Python's slice object?
- Coding, Fast and Slow, Just Like Chess An essay: How adapting from fast to slow chess got me thinking about coding in Python
- Butter Berries, An Elusive Delicacy (Paid article) How my quest to find butter berries at the supermarket led to musings about Python lists and dictionaries and more
- Pay As You Go • Generate Data Using Generators (Data Structure Categories #7) Generators • Part 7 of the Data Structure Categories Series
Recently published articles on Breaking the Rules, my other substack about narrative technical writing:
- The Consequential Detail (Ep. 12). Can a single letter or one blank line make a difference? (Spoiler Alert: Yes)
- The Unexpected Audience (Ep. 11). What I'm learning from listening to Feynman's physics lectures
- The Story So Far (Mid-Season* Review). Are you back from your holidays? Catch up with what you've missed
- Broken Rules (Ep. 10). Let's not lose sight of why it's good to break the rules—sometimes
- Frame It • Part 2 (Ep. 9). Why and when to use story-framing
- The Rhythm of Your Words (Ep. 8). Can you control your audience's pace and rhythm when they read your article?
Stats on the Stack
- Age: 5 months, 3 weeks, and 6 days old
- Number of articles: 33
- Subscribers: 1,108
Each article is the result of years of experience and many hours of work. Hope you enjoy each one and find them useful. If you're in a position to do so, you can support this Substack further with a paid subscription. In addition to supporting this work, you'll get access to the full archive of articles and some paid-only articles.