P2-7.1 Local Environment and Runtime¶

Section ID: P2-7.1 Version: v2026.07.20

In P2-3.5, we first separated Colab and a local PC. At that time, the purpose was a preliminary guide so the reader could immediately follow the NumPy practice. Now we step down one layer more basic.

Up through P2-6, we read what is being calculated, such as formulas, loss, and optimization. But in reality, those calculations are executed somewhere, and some program has to read them before we can confirm them with our eyes. Starting from this Section, we are not pausing mathematical language. We are entering the part where we read the environment that turns those calculations into actual executable statements.

If we compress this transition in the shortest possible way, it becomes the following.

Here we explain the large distinction between local environment and runtime. Even if later Sections continue into terms such as terminal, interpreter, virtual environment, and dependency, the big picture of these two terms reconnects on top of the explanation here.

Rather than following Python installation screens one by one, this Section focuses on distinguishing where calculations are actually executed and who manages that place. If you first secure the relationship among local environment, runtime, Colab, and a local PC here, then when you later see terminal, interpreter, and virtual environment, you will read them not as am I learning another new tool again? but as am I dividing the same execution place more finely?

First, look at the smallest execution scene. The examples below all have the same goal.

Where should hello actually be typed so it runs?

Problem situation: if you get confused about where to put the same hello, then explanations of the runtime can feel abstract. Input: one terminal command and one line of Python code. Expected output: in the terminal, the Python version appears; in the Python-code position, hello appears. Concept to check: before asking what code do we write?, we first see that where do we put it? is different.

1

python --version

1
2

# This is the smallest output check for whether Python code is running.
print("hello")

The minimum distinction that must be fixed right here is two things.

• python --version is a command placed into the terminal.
• print("hello") is Python code placed into a Python interpreter or notebook cell.

In other words, saying that we distinguish the runtime starts not from grand installation theory, but from knowing the fact that even if they look like the same screen, the place where you type can be different.

First Places to Return to by Problem Type¶

Chapter 7 is more efficient when you return to it by the kind of problem where you got stuck rather than reading everything in one sweep.

The purpose of this table is not to make the reader memorize Chapter 7. It is to let the reader immediately find the shortest return path by the type of blockage they have right now.

Here we explain for readers who may not have basic programming knowledge. If you already know terminal, Python, and virtual environments, some of this may feel familiar, but these are words that repeat throughout later practice, so they need to be organized once.

This Section reads around the following four questions.

• Where is code executed?
• What does Python execute?
• What is different between local environment and runtime?
• Why does the phrase virtual environment appear?

This question can look more practical than AI mathematics. But it is very important in machine-learning practice. Even with the same code, if the runtime is different, the result can differ or the code may not run at all.

In other words, the reason we learn these words now is simple. Later, when we create NumPy arrays, read Pandas data, and receive example projects with Git, we must be able to first distinguish why does the code not run? as a runtime problem rather than as a mathematics problem.

When reading Part 2 Chapters 7 through 10 afterward, keep the following three layers separate.

The key point of this table is that terminal, Python syntax, and notebooks may all sit under one name called studying Python, but they do not play the same role. Among them, Chapter 7 first distinguishes execution place and manager.

If we compress this flow more briefly using Part 2 Chapters 7 through 10, it becomes the following.

If we connect this transition to the surrounding Chapters at once, it can be organized like this.

So the core of this Chapter is that the handle changes from what shall we calculate? to where shall we execute that calculation?

Core Criteria: Local Environment and Runtime¶

• You can explain local environment as the conditions under which code runs on my computer.
• You can explain runtime as the place where code actually runs.
• You can explain why terminal, Python interpreter, and virtual environment appear in that order.
• You can explain that Colab and a local PC are both runtimes, but their management styles differ.

Three Criteria¶

Here we distinguish the place where code runs, rather than the installation procedure itself. The following three criteria become the basis that ties together the later explanations of installation, terminal, and virtual environment.

Why Does Python Appear So Often?¶

When studying AI, Python appears often. At that point the question can arise, why Python in particular?

Python was first developed by Guido van Rossum in the late 1980s and released in 1991. The official Python FAQ explains that Python was influenced by the experience of the ABC language and arose from the need for a more extensible scripting language in a situation where system-administration tasks were hard to handle only with C programs or shell scripts.

What matters in this history is that Python was from the start both a high-level language easy for humans to read and write and an execution tool connected to real system work.

That is why Python fits learning, automation, data processing, and experiment code well. The official Python FAQ also explains that Python is suitable as a first language because it has clear syntax, a large standard library, and an interactive interpreter.

The reason Python appears often in AI is connected to this same flow.

• It is easy to move formulas into code.
• Small experiments can be run quickly.
• There are many tools such as NumPy, Pandas, and Matplotlib.
• Many machine-learning and deep-learning libraries gather in the Python ecosystem.

Of course, that does not mean Python is the only language. Inside real services, languages such as C++, Java, JavaScript, Go, and Rust are also used together. But at the entrance to AI learning and experimentation, there is a high chance of meeting Python. So in this Chapter, before installation, we first secure where and how Python code is executed.

First Think About the Place Where Code Runs¶

When someone first begins programming, the phrase write code appears first. But code does not move by text alone. A program that reads and executes the code, and a place where it is executed, are needed.

Here we have to distinguish three words.

• code: a command written by a person
• execution: the computer processing that command
• runtime: the place where the programs, settings, packages, and files needed for execution are prepared

For example, the following is Python code.

Problem situation: we look at the smallest example that separates merely writing text from actually running it. Input: one line of Python code that prints a string. Expected output: if the Python interpreter reads it, hello is printed. Concept to check: Python code becomes actual action only when there is a runtime and an interpreter.

1
2

# The same print code can run in a different place depending on the runtime environment.
print("hello")

But if we only write this sentence in a text editor, nothing happens. The Python interpreter must read and execute this sentence.

The Python Interpreter Is the Program That Reads and Executes Code¶

The Python interpreter is the program that reads and executes Python code. The official Python documentation explains that the Python interpreter can be invoked from the command line, and that in interactive mode commands can be entered at the >>> prompt.

Here we distinguish Python code and the Python interpreter as follows.

• Python code: a command written by a person
• Python interpreter: the program that reads and executes that command

There are several ways to run Python.

These three can look mixed. What matters is that they all share the same point: the Python interpreter executes Python code.

Python interpreter and script execution are revisited again in P2-7.3. Here, remember only the big picture that Python code is executed by the Python interpreter.

The Terminal Is the Window for Sending Commands to the Computer¶

The terminal is the window where we enter commands to the computer. Programs such as Terminal on macOS, Windows Terminal, PowerShell, and a Linux shell belong here.

Terminal commands and Python code are different.

1

python --version

The command above is a command executed in the terminal. It is not a sentence written exactly as it is inside a Python code file.

By contrast, the following is Python code.

Problem situation: in contrast with a terminal command, we check again in what place Python code is written. Input: Python code that prints a string. Expected output: if run as Python code, hello is printed. Concept to check: even if they look like similar sentences, terminal commands and Python code belong to different input places.

1
2

# The Python statement stays the same even when the runtime changes.
print("hello")

This distinction matters.

Here too, we read by separating roles.

• terminal command: runs Python, installs packages, or executes files
• Python code: code read by the Python interpreter

The places that are often confusing are the following.

There is a reason we check again here the distinction we saw in P2-3.5. If we do not know the execution place, then when an error appears it becomes hard to judge what exactly should be fixed.

Terminal, shell, and working directory are handled separately in P2-7.2. Here, secure only the point that terminal commands and Python code are not the same sentence.

The Local Environment Is the Execution Condition on My Computer¶

The local environment means the conditions under which code runs inside my computer. This can include the operating system, Python installation location, package installation state, current working folder, and environment variables.

Here we treat the local environment as the conditions under which Python code runs on my computer.

Even with the same code, the result can differ by computer.

For example, conditions can differ between computers in the following way.

• NumPy may be installed on my computer, but not on another computer.
• My computer may use Python 3.12, while another may use Python 3.10.
• A file path may be correct on my computer, but the file location may differ on another computer.

That is why in practice documents, where is it executed? matters as much as the code itself.

The Runtime Is the Place Where Code Actually Runs¶

The runtime is the place where code actually runs. If you run on a local PC, your computer becomes the runtime. If you run on Colab, the notebook runtime provided by Google becomes the runtime.

Colab is convenient. It can run in the browser without Python installation. But the runtime can disconnect, files can disappear, or the service policy can change.

A local PC is troublesome at first to set up. But you can directly manage your project files, package versions, and execution style.

In summary, it is as follows.

• Colab: easy to start with, and the runtime is managed by an external service.
• local PC: requires initial setup, but I manage the runtime.

The Virtual Environment Is a Project-by-Project Execution Space¶

A virtual environment is a device that creates a separate execution space for each Python project. The official Python documentation explains that venv creates lightweight virtual environments and that each virtual environment can have an independent set of Python packages.

You can understand a virtual environment as the Python execution space for each project.

Why is it needed? Project A may need numpy 1.x, while project B may need numpy 2.x. If both are installed all mixed together on one computer, they can conflict, so the space is divided by project.

A virtual environment is not the project code itself. The official Python documentation also explains that virtual environments are usually created in directories such as .venv or venv, and are not put into source-control systems. In any project, .venv is the local environment for execution, not the body text file or code itself.

A commonly seen command is the following.

Problem situation: we first become familiar with what a command that creates a project-by-project execution space actually looks like. Input: the terminal command python -m venv .venv. Expected output: a virtual-environment directory called .venv is created. Concept to check: a virtual environment is not only a conceptual explanation, but is connected to the command that actually creates a Python space by project.

1

python -m venv .venv

This command creates a virtual-environment directory called .venv. Here we do not memorize the OS-specific activation command. For now, secure only the meaning that it creates the execution space by project.

Virtual-environment creation and package installation are revisited in P2-7.4. Here, we look only at the reason why a virtual environment is needed.

A Package Is a Bundle of Code Borrowed for Use¶

A package is a bundle of code created by someone else. Tools such as NumPy, Pandas, and Matplotlib belong here.

Here we read by distinguishing three layers.

• Python: the language and execution program
• package: the bundle of code borrowed inside Python
• pip: the tool that installs packages

For example, the command that installs NumPy and the code that imports it are different.

1

python -m pip install numpy

Problem situation: immediately after the installation command, we check how the position of installation and the position of Python code differ. Input: Python code that imports NumPy under the name np. Expected output: there is no printed output, but the current Python code becomes ready to use NumPy. Concept to check: package installation is done in the terminal, while import happens inside Python code.

1
2

# This checks whether NumPy can be imported in the current runtime environment.
import numpy as np

The first is installation. The second is the act of loading it for use inside Python code.

Package, dependency, and reproducibility are treated in more detail in P2-7.4 and P2-7.5. Here, keep only the point that installation and use are different actions.

If You Do Not Know Programming, What Should You Distinguish First?¶

Rather than memorizing a lot of syntax, it is more important to secure distinctions first.

This distinction is not itself a concept of machine learning. But in the process of learning machine learning, it can keep grabbing your ankle. So we organize it first in this Chapter.

View It Through a Case¶

Case 1. The Same Example File Works in Colab but Not on My Computer¶

Suppose a learner ran a book example in Colab and it worked well, but after downloading the same file and running it on a local PC, an error appeared. People often first suspect is the code wrong? or was the download wrong?

But in this situation, before syntax, the execution place must be distinguished first. In Colab, the code may already be using a prepared runtime and packages, while on the local PC the Python interpreter, working folder, and package installation state have to be checked directly.

The words emphasized in this Section, local environment, runtime, interpreter, and virtual environment, are exactly the language for reading this failure in separated pieces. In other words, if we distinguish where was it executed?, who executed it?, and are the needed packages present in that place?, then the problem can be narrowed down faster.

The confirmable result is simple. If import numpy as np works immediately in Colab but raises ModuleNotFoundError on the local PC, then we can conclude that before the code content, the package-preparation state of the local runtime should be checked first.

Checklist¶

• You can explain local environment as the conditions under which code runs on my computer.
• You can explain runtime as the place where code actually runs.
• You can distinguish terminal commands from Python code.
• You can explain the Python interpreter as the program that reads and executes Python code.
• You can explain a virtual environment to the degree that it is the execution space for each project.
• You can explain at an introductory level that package installation and import are different actions.
• You can explain that Colab and a local PC are both runtimes, but their management styles differ.
• You can first check where it runs, what executes it, what package is needed, and where that package is installed.

Sources and References¶

• Python Software Foundation, Using the Python Interpreter, Python 3.14.6 documentation, checked 2026-07-20. Used to support invoking the Python interpreter and distinguishing interactive input from script execution.
• Python Software Foundation, General Python FAQ, Python 3.14.6 documentation, checked 2026-07-20. Used to confirm the basic description of Python as an interpreted, interactive programming language available on multiple operating systems.
• Python Software Foundation, venv — Creation of virtual environments, Python 3.14.6 documentation, checked 2026-07-20. Used to confirm that a virtual environment has its own Python installation and package state inside an isolated directory.
• Python Packaging Authority, Install packages in a virtual environment using pip and venv, Python Packaging User Guide, checked 2026-07-20. Used to confirm the project-level flow of creating a virtual environment, activating it, and installing packages.