Build Your Workspace

Core path: 35 minutes

By now the editor, terminal, files, folders, and Python interpreter should no longer look like one giant mystery box. They are separate pieces. Lesson 4 makes you use them together.

You are going to build a small project, navigate it from the terminal, break one file on purpose, and prove that you understand where Python is looking when you run a command.

That last part matters. A surprising amount of beginner frustration is not bad Python. It is the right file in the wrong folder, the wrong file in the right folder, or a terminal sitting somewhere the student forgot about.

Build the project first

Use the full Python workspace provided by your class or a local VS Code + Python installation. A managed Codespace is fine when your school provides access. The inline Robotnix runner is not enough for this lesson because the filesystem and shell are part of what you are learning.

Before creating anything, run:

pwd
ls

Look at the output. pwd tells you the current working directory. ls tells you what is visible from that location.

Do not treat those commands as decoration. They answer two different questions:

• Where am I?
• What can I see from here?

Now build:

week02-project/
├── README.md
├── main.py
├── experiments/
│   ├── hello.py
│   └── broken.py
└── notes/
    └── observations.md

From inside week02-project, create the directories:

mkdir experiments
mkdir notes

Run ls again. Your claim that the folders exist should be supported by output, not memory.

Put code in the right places

Create main.py:

print("FROM CODE TO AI")
print("Development environment ready.")

Create experiments/hello.py:

print("Hello from the experiments folder.")

Create experiments/broken.py with an intentional syntax error:

print("This program is broken"

Now run the project from the root:

python main.py
cd experiments
python hello.py
python broken.py

The broken program should fail. Good. Read the error before touching the file.

Record:

• the command you typed;
• the file Python says it was reading;
• the line number;
• the error type or message;
• what you think the problem is.

Then repair the file:

print("This program used to be broken.")

Run it again.

The important evidence is not merely that the second run succeeded. The important evidence is that one source change produced a different execution result.

Now create a path failure

Return to the project root:

cd ..

Confirm:

pwd
ls

Now type:

python hello.py

That command should fail because hello.py is not in the project root. It is inside experiments/.

Nothing is wrong with hello.py.

Nothing is wrong with the interpreter.

The command is asking Python to open a file at the wrong path.

Prove two valid repairs.

One option is to move into the directory:

cd experiments
python hello.py

Another is to stay at the project root and provide the relative path:

python experiments/hello.py

Same file. Different way of locating it.

Leave evidence for future you

Create notes/observations.md and record enough information that another person could reconstruct what happened:

# Week 02 Workspace Evidence

## Starting location
pwd:

## Project tree
What I created:

## Syntax failure
Command:
Error:
Cause:
Fix:

## Path failure
Command:
Error:
Cause:
Two valid repairs:

You are finished when somebody can inspect the project and verify all of these claims:

• the required files exist in the correct directories;
• main.py and experiments/hello.py run when addressed correctly;
• you preserved one real Python failure before fixing it;
• you can explain the difference between a code error and a path/location error; and
• you can prove where your terminal was when each command ran.

That is a development environment. Not a theme. Not an editor window. A set of tools whose state you can actually inspect.