Meet Your Development Environment

Core path: 30 minutes

When you click Run, what is actually doing the work?

Week 1 separated source code from execution. This week adds the tools around that process.

The first thing I want to kill early is a very common mental shortcut:

VS Code is Python.

Nope.

VS Code can display and edit Python source. Python is the language and runtime that executes the source. The terminal is another interface. The filesystem stores the project. The operating system connects all of those pieces.

If we blur those layers together, every failure turns into "VS Code is broken." That diagnosis is usually useless.

Concept flow

How the development environment fits together

The editor changes project files, the terminal runs commands in that project, and the Python interpreter executes the program.

1. 

   EDITORwrite and inspect code
   saves
2. PROJECT FILESyour .py files on disk
   selected from
3. TERMINALrun commands in the working directory
   starts
4. 

   PYTHONreads and executes the program

Read the strip as a chain of responsibility, not as a list of brands:

• the editor changes source text;
• the file stores the saved text;
• the terminal/shell launches commands;
• the Python interpreter reads and executes the file;
• the output is evidence of what happened during that run.

The editor is one layer

Open a Python file in VS Code or the editor your class provides.

You can type:

print("Robot online")

At that moment, you have changed text in an editor buffer.

If the file has not been saved yet, the copy on disk may still contain the old version.

That distinction sounds boring until you spend ten minutes wondering why your "new code" is producing the old output.

Try this deliberately:

1. save a file containing print("Version 1");
2. change the editor to print("Version 2");
3. do not save yet;
4. notice the editor's unsaved-change indicator;
5. save;
6. run the file.

The useful chain is:

editor buffer changed
        ↓ save
file on disk changed
        ↓ execute
Python reads saved source
        ↓
output changes

The editor did not execute the program merely because the text changed.

What exactly is an IDE?

You will hear IDE, short for Integrated Development Environment.

The term describes a workspace that brings several development tools together. A typical environment may include:

• source-code editor;
• file explorer;
• integrated terminal;
• debugger;
• extension system;
• version-control interface;
• language assistance such as syntax highlighting and completion.

VS Code is often described as a code editor that can be extended into a larger development environment. You do not need to win an argument over the label.

You need to know which layer is responsible for what.

Tour the interface with a purpose

Locate these areas in your environment:

Explorer — shows files and folders in the opened project/workspace.

Editor — shows the contents of the file you are reading or changing.

Tabs — show which files are open in the editor. An open tab is not the same thing as a file being executed.

Terminal — displays a shell session where commands can be entered.

Status bar — shows context such as language mode, selected interpreter, Git branch, line/column, or other workspace state depending on configuration.

Command Palette — searchable access to editor actions.

The interface is useful because it exposes several tools in one place. It can also hide the boundaries between them if you never ask what is happening underneath.

The Explorer is not the filesystem itself

The Explorer is a view of the filesystem.

If you create a folder from the terminal later with:

mkdir experiments

the folder can appear in the Explorer because both tools are interacting with the same underlying project files.

That does not mean the terminal "created something inside VS Code." It changed the filesystem, and the Explorer refreshed its view.

This distinction matters beyond Python. The interface is one layer. The state underneath is another.

The Run button is a convenience, not magic

Depending on your environment, a triangular Run button may launch Python for you.

That is convenient.

But I still want you to learn the terminal form:

python hello.py

Why? Because the explicit command exposes useful facts:

python     → which program should execute?
hello.py   → which file should it receive?
current directory → where should the shell look for that file?

A button can hide those details. Hiding details is fine after you understand them. It is terrible when you are debugging something you never learned was there.

Use the Command Palette instead of memorizing the whole interface

Press:

Ctrl + Shift + P

or Cmd + Shift + P on macOS.

Search for a command such as:

Terminal
Format Document
New File

Developers do not carry a mental map of every menu item in every tool. They learn how to find the operation they need.

That skill survives interface redesigns better than memorizing which submenu contained a button last year.

Guided example: the screen says one thing, the runtime says another

Suppose your editor visibly contains:

print("Version 2")

but running the program prints:

Version 1

Do not immediately reinstall Python.

Start with the layers:

1. Is the editor change saved?
2. Which file path are you actually running?
3. Which directory is the terminal in?
4. Which Python interpreter is being launched?

One of those questions usually produces more evidence than ten random fixes.

Different classrooms, same architecture

Your class may use:

• local VS Code + Python;
• a teacher-provisioned browser IDE;
• a managed Codespace;
• another approved development environment.

The buttons may move. The architecture stays recognizable:

EDITOR → FILES → TERMINAL/SHELL → PYTHON → OUTPUT

Lesson 2 focuses on the files. Lesson 3 focuses on the shell. By Lesson 5, you will prove which interpreter and file the environment is actually using.