Running Python Programs

Two places Python can execute code

Python's interpreter is a program that reads Python code and executes it. One way to use it is interactively: start the interpreter with no program file and, when standard input is a terminal, it presents a primary prompt. You enter one expression or statement at a time. For example, entering 2 + 3 produces 5. That short feedback loop is useful when you want to check what a small expression does. It is not a permanent record of a program unless you separately save the code.

The other common mode is a script: a text file containing Python code, conventionally named with .py. Giving that file's path to the interpreter asks Python to read and execute the file. From the directory that contains hello.py, the command python3 hello.py runs it. The important general idea is not one shell spelling: identify the Python interpreter your environment provides, then pass it the path to the script. An IDE's Run button normally performs that same broad operation for a selected file, but you should still know which file it is running and where its output appears.

A script is valuable because the exact statements can be run again. If hello.py contains print("hello from a file"), each successful run writes that line to standard output. The lesson is not that every program should be launched from a terminal; it is that the file, interpreter, current location, and output panel are the pieces to check when you ask, “What did I run?”

Top-level execution and the main guard

Every module has a __name__ value. Python documents a special top-level code environment named __main__. When Python executes a file as the top-level program, it sets that file's __name__ to the string '__main__'. That makes this small conditional useful:

if __name__ == "__main__": announce()

The indented call runs when the file is launched as a program. If another program loads the file to use its definitions, the condition is false because the loaded module has its module name instead. The guard is therefore a narrow control over what happens automatically at top level. It is not a requirement for every tiny script, and it does not replace a full discussion of imports or module design. Its beginner-level value is simple: define reusable pieces above it, then put the “start this program” action inside it.

For instance, a file can define announce() to print started, then call it only under the main guard. Direct execution prints started. Loading the same file under another module name makes the function available without that automatic print. This distinction prevents surprising side effects when code meant for reuse is loaded elsewhere.

Observe output, errors, and the exact run

Program output is evidence of one execution. It tells you what the program wrote, but it must be read with the command or run configuration that produced it. A fast, documented option for a one-line experiment is python3 -c 'print(2 + 3)', which prints 5; this is convenient for a quick check but does not create a script file. For a saved program, rerunning the same file repeats its statements in order while no unhandled error intervenes.

When an exception is unhandled, Python prints a traceback to show the path of calls that led to it. In a simple top-level script, the traceback identifies the file and line that failed, and its final line names the exception. A file containing print("before"), then 1 / 0, then print("after") writes before, reports ZeroDivisionError: division by zero, and never reaches after. The path on your machine will differ, so do not memorize a path from an example; find the path and line in your own traceback.

This is observation, not yet a debugging method. Before changing code, verify that you ran the intended file, inspect the normal output in order, and read the exception type and location. Those checks avoid a common beginner confusion: editing one copy of a file while an IDE or terminal is executing another one.