Reading an error message

TL;DR#

This morning was setup: your repository became a project, today's notebook opened on your own machine, and an agent started answering inside it on your Babson key. The notebook has three jobs: getting marimo running, taking the whole workflow through once including working with AI, and running Python before you have been taught its syntax. Then the topic itself, which is what to do when Python stops and prints something at you. Read the last line first. It names the error and points at the line that caused it.

What we covered#

Where to get data, from the follow-up to this morning's lightning talk. An argument about pricing becomes analysis the moment you have numbers, and for most questions the data is not yours to collect. Researchers who study pricing get it from inside the company: John List was Uber's first chief economist and later Lyft's, and that access is what his results rest on. Everyone else works from public data.

Kaggle is where to start, and two things on it are worth your time. Datasets are downloadable and mostly already cleaned. Code holds the notebooks other people published against those datasets, which are free worked examples of the analysis you are learning to write. More sources come later in the course.

Commit, push, pull, and what a conflict actually is. A commit saves a set of changes on your machine. Nothing appears on github.com until you push, which was demonstrated by committing twice and refreshing the page to find nothing there. A pull brings the remote version down to you. When the same file changed in both places, the push fails until you pull, and then you choose: keep your version, take the incoming one, or keep both. The tool shows you both sides and you decide. You are unlikely to meet a conflict this term unless you work on two machines.

Fetch is refresh. It asks github.com whether anything has changed and moves no code. And the timestamp on a commit is real: if you did the work and forgot to push, push it late and the history still shows when you made it.

Open source, which started as a question about collaboration. Git exists because thousands of people need to change the same code without overwriting each other. The way in from the outside is a fork, your own copy, then a branch for the change you are making, then a pull request, which is a request that your change be merged into the original. Linux has over nineteen thousand contributors working that way. So does Python: the interpreter uv installed on your machine is itself open source, with over three thousand contributors.

Which window is which. GitHub Desktop moves commits between your machine and github.com. VS Code is where you write code, run it, and open a terminal. marimo in the browser is where the notebooks run. github.com is the copy other people can see. A prompt reading PS C:\...> or ending in % is the operating system waiting for a command. Three angle brackets, >>>, means you are inside Python and terminal commands like uv will not work there until you leave with exit().

Anything you type at >>> disappears when you leave it. That makes it good for a quick check and useless for real work, which is the whole reason files exist.

Your repository became a project. uv init --app --no-package --python 3.14 adds three files. .python-version pins the Python version, so a Mac that ships an old one does not quietly use it. pyproject.toml records what your project needs, which is how every package from here on is tracked. main.py you can ignore or delete. Then uv add marimo installed marimo into that project permanently, rather than for one session.

Keep marimo's cache out of your repository. marimo writes every cell's output into a folder called __marimo__/ beside your notebook. That is why your .py file stays clean, and it is also a folder that changes every time you run anything. Open the .gitignore in the root folder of your repository and make sure it has a line reading __marimo__/. If you do not have a .gitignore at all, download one from /downloads/ and drag it in beside README.md.

The agent, inside the notebook. Your Babson key goes into marimo as a custom provider, and the model name carries the provider with it: babson_ai/claude-sonnet-5. Set all four boxes: the provider and model under CODE COMPLETION, and the chat and edit models under AI ASSISTANT. A box left empty shows no error and simply never answers.

The reason for doing it this way, rather than keeping a chat window open in another tab, is that the agent can see your notebook. Ask it about a cell and it reads the cell. Ask it about an error and it finds the error. Manual mode proposes a cell and waits for you to accept it; agent mode goes and does the work, using tools, and reports back. Both are the same model and the same key.

That is also why the budget is worth thinking about. Re-running a failing cell twenty times without reading the message costs more than twenty good questions.

Your key is yours. It is billed to Babson and attributed to you. It does not go into a file in your repository, and it does not go to anyone else.

Reading an error message. Two turned up this morning, neither of them planted:

• NameError means Python has never seen that name. Almost always a typo. Python is case sensitive, so freight_charges and Freight_charges are two different names as far as it is concerned.
• IndexError means you asked for a position that does not exist. Counting starts at zero, so a list of five has positions 0, 1, 2, 3 and 4. There is no 5.

When one of these appears, do not fix it immediately. Read which error it is, read which line it points at, and then decide what to change. Getting an error is cheap and finding out later that a number was wrong is not.

len is the same idea in three places. It gives the number of items in a list, the number of characters in a piece of text, and the number of pairs in a dictionary. It does not work on a number, because a number is not made of parts. The pattern matters more than the function: when you meet a new kind of data, the first useful question is which of the things you already know still work on it.

Predict, then run. Before you run a cell, especially one an agent wrote for you, say what you expect to see. Then run it and compare. The cells that surprise you are the ones you learn from, which is why the notebook keeps asking you to write the prediction down first.

When the setup does not work#

None of these means anything is wrong with your machine.

• uv is not recognised, or command not found. Quit VS Code completely and reopen it from GitHub Desktop. A terminal reads the list of available programs once, when it opens.
• error: Project is already initialized. You did this before. Skip to uv add marimo.
• No pyproject.toml found. The terminal is in a different folder. Open VS Code from GitHub Desktop again so it opens on your repository.
• The first chat message fails with ModuleNotFoundError: pydantic_ai, even though the settings screen says Configured. The extra packages are missing. Stop marimo with Ctrl+C, which is Ctrl and not Cmd on a Mac too, then answer y, run uv add "marimo[recommended]", then start it again with uv run marimo edit. Stopping marimo first is the step people skip and the one that matters.
• marimo will not start, or the terminal says uv trampoline failed to canonicalize script path. The virtual environment is broken. Delete the .venv folder in your repository, then run uv add "marimo[recommended]" again. It rebuilds from pyproject.toml, so you lose nothing.
• There is no robot icon and no Chat & Agents panel. Enable AI features is unticked, on the AI Features tab of the AI settings. With it off, everything else you configure has no effect, including a provider that says Configured.
• connection error on every message, with the key, the URL and all four boxes checked. A few people hit this and it is not something you can fix by retyping the setup. Check once for a space at either end of the key and for anything added to the end of the gateway URL. If it still fails, email me the exact message and I will take it to the AI team. The problem is on the other side of the gateway, not on your machine.
• Your machine is slow, or an install crawls. It is usually memory, and usually a browser with forty tabs open. On Windows, Ctrl+Shift+Esc opens Task Manager; sort by Memory. On macOS, Cmd+Space, then Activity Monitor, then the Memory tab. Close what you are not using before a long install.

Everything above, with screenshots, is on Your Babson AI Key and Getting Started.

Two corrections from this morning#

Ctrl+Enter and Shift+Enter are not quite the same. I said they were.

• Ctrl+Enter runs the cell and leaves you in it.
• Shift+Enter runs the cell and moves to the next one, creating a new cell if there is nothing below. It is the one to use while you are writing a sequence of cells.

They looked identical this morning because every cell already had something under it. Ctrl+Shift+H inside a notebook lists every shortcut.

Revert in GitHub Desktop does not take your repository back to an earlier point. I described it as time travel and it is not. Right-clicking a commit and choosing Revert adds a new commit that undoes that one change, and leaves everything that came after it in place. It is a useful thing, but it is not an undo button for your whole project, and you do not need it this term.

One thing I understated#

Lightning talks are optional, and the bonus is bigger than I said in the room. The syllabus is exact: a talk adds one point to your final grade, not one point inside the participation component. Only one talk counts, and your final grade is still capped at 100. Nobody loses anything by not giving one. Sign-up is at /lightning/.

The format is four minutes: two minutes on something you built, broke or found, then two minutes of discussion that you run yourself, ending on a question people can disagree about. This morning's ran considerably longer than that, which was my fault for not saying the number before we started. Four minutes from now on.

What we did not get to#

We ran out of clock before four things, and all of them are in today's notebook with explanations around them:

• Types and f-strings: int, float, str, bool, and how to put a number inside a sentence
• for, if and .append(): going through a list and keeping some of it
• The other errors you will meet first: ModuleNotFoundError, FileNotFoundError, SyntaxError
• Markdown, which is how you write the text cells in a notebook

If the second half of the notebook feels like it is asking for something you have not seen, that is why, and it is not you. Work through it in order, read what each section says before you run its code, and use the agent beside it, which is what it is there for. Bring whatever does not land to next session or to office hours.

Public links#

• Your Babson AI Key, the full setup for marimo and for VS Code
• Where Am I Typing?, the three prompts and which window is which
• Python Projects, including where each kind of file goes
• What to Commit, and why __marimo__/ and .venv/ stay out
• Git and GitHub
• Markdown, which we did not reach in the room
• Python Essentials and Collections. The sections behind today's notebook are Types, Expressions, f-strings, Reading a traceback, Lists, and Iterating over a list
• Kaggle, public datasets and the notebooks other people wrote against them
• marimo keyboard shortcuts

Before next session#

1. Work through the whole notebook and push it. Every section, including the ones we did not reach in class. Run the cells, read what they show, write down your predictions where a section asks for one, and write the code where it asks for that. Use your agent for the sections we did not get to, which is what it is for. Push it by the end of Sunday, so I can read it and get back to you on Monday. Saving is not pushing: save the file, then commit and push in GitHub Desktop.
2. Put the notebook in a folder called notebooks/ in the root folder of your repository, if it is not there already. Lowercase, plural, no space. Everything from here on assumes it.
3. The last section, A Question About Your Own Numbers, is optional this week. Nothing is graded on it. It is the first thing in this course that is yours rather than mine, so it is worth the hour if you have one, and you lose nothing by skipping it.
4. If your agent is not answering, work through the fixes above. If it still will not, email me the exact error rather than retyping the setup from scratch.

Checkpoint 1 closes Sunday 9/20 and covers the first two sessions. Each item is simply present or absent: a public repository named oim6301, more than one commit in each week it covers, the notebook in it, the notebook worked through, and commit messages that say what changed. The full checklist is on Canvas.