Orientation: Running and Reading Python

Why it matters

“Python” usually refers to three different things at once: a language specification, a program that runs it, and a large library that ships alongside it. Keeping those apart early avoids a whole category of confusion later — “is this guaranteed, or does it just happen to work on my machine?” — and getting comfortable running a program three different ways, and reading its tracebacks calmly, makes every lesson after this one faster to work through.

Mental model

Python is a language specification: the grammar, the built-in types, the rules for how code behaves. CPython is the program — the interpreter — that most people mean when they type python: it reads your source, compiles it to an internal bytecode form, and executes that bytecode. It’s the reference implementation and by far the most common one, but it isn’t the only one (PyPy and MicroPython exist for different goals). The standard library is the large collection of ready-to-use modules (json, pathlib, math, and hundreds more) that ships with every CPython install.

Worked example: three ways to run the same program

The same short program, run three different ways, produces the same output every time — because it only uses language features, nothing implementation- or environment-specific.

def greet(name: str) -> str:
    if name:
        return f"Hello, {name}!"
    return "Hello, stranger!"


def main() -> None:
    print(greet("Ada"))
    print(greet(""))


if __name__ == "__main__":
    main()

Hello, Ada!
Hello, stranger!

Running the same file with python3 orientation_and_execution.py, or with py orientation_and_execution.py on Windows, prints the identical two lines — only the launcher command differs, not the language underneath it.

Common mistakes: reading a traceback

Errors are evidence, not failures — and Python hands you a specific, structured report to work from. Suppose the call site had a typo:

def greet(name: str) -> str:
    if name:
        return f"Hello, {name}!"
    return "Hello, stranger!"


print(greett("Ada"))

Traceback (most recent call last):
  File "orientation_and_execution.py", line 6, in <module>
    print(greett("Ada"))
          ^^^^^^
NameError: name 'greett' is not defined. Did you mean: 'greet'?

A NameError means the code was syntactically valid — it parsed and started running — but at the moment that line executed, no binding named greett existed. Compare that with a mistake the interpreter catches before running anything at all, such as a missing closing parenthesis: that raises a SyntaxError, and in that case no line of the file runs, not even ones before the typo, because the file never became valid Python to begin with.

Check your understanding

Practice: warm-up

Save the worked example above as orientation_and_execution.py. Run it three ways: paste the two function definitions and the two print(greet(...)) lines into a REPL one block at a time; run it as a script (python orientation_and_execution.py); and run it as a module from its parent directory (python -m orientation_and_execution, no .py). Note anything that differs between the three.

REPL (paste definitions, then each print call):
    Hello, Ada!
    Hello, stranger!
    (each printed immediately after its own print(...) line is entered)

python orientation_and_execution.py:
    Hello, Ada!
    Hello, stranger!

python -m orientation_and_execution (run from the file's own directory):
    Hello, Ada!
    Hello, stranger!

Practice: apply it

Introduce the typo from the traceback example above (greett instead of greet) into your saved file and run it again.

Modification challenge: fix the typo, then add a third call, print(greet(42)). Predict what happens before running it — name: str is a type hint, not an enforced constraint at runtime, so nothing stops you from passing an int.

Summary

• “Python” is the language; CPython is the interpreter most people run; the standard library ships alongside CPython. Content on this site labels which of these a claim depends on.
• The REPL, a script file, and python -m all run the same language the same way — only how the code reaches the interpreter differs, not what it means once running.
• Blocks are marked by indentation, not braces — see Indentation and Blocks for the exact rules.
• A traceback is read bottom-up: the last line names the exception and its message, and the line just above it points at the exact source location — that’s where the real cause almost always is.
• SyntaxError (including IndentationError) means the file never became valid Python, so nothing in it ran at all; NameError, TypeError, and similar exceptions mean the code parsed fine but something went wrong while it was actually executing.