Interpreter and Program Basics

Choose between exploring and running

Before writing a single line, decide how the code will reach the interpreter. That choice is not cosmetic: it decides whether you get an immediate answer to one idea or a repeatable program you can run again tomorrow.

The interpreter behaves somewhat like a Unix shell. When it is called with its standard input connected to a terminal, it reads and executes commands interactively. When it is called with a file name argument, or with a file as standard input, it reads and executes a script from that file.

These are two distinct working modes, and everything else in this concept is a variation on one of them.

The command that starts the interpreter is not fixed. The directory where the interpreter lives is an installation option: on many Unix machines it is /usr/local/bin/python3.14, and putting that directory on the shell search path makes python3.14 enough to start it. Other locations are possible, and on Windows the python3.14 command is available after a Microsoft Store install, while the py command comes from the py.exe launcher.

So python in the command forms below stands for whichever launcher is correct on your machine, not for a universal program name.

To leave an interactive session, type the end-of-file character at the primary prompt — Control-D on Unix, Control-Z on Windows. If that does nothing, call quit().

Send code without writing a script file

Two command-line forms let you run Python without creating a file at all, and they are easy to confuse because both take something that looks like a name.

The form python -c command [arg] ... executes the statements inside command. Python statements often contain spaces and other characters that the shell treats specially, so the complete command is usually quoted:

python -c "print(2 + 2)"

The form python -m module [arg] ... locates a module and executes its source as a script, exactly as if you had spelled out its full path on the command line. It is how a module that is also useful as a tool gets run.

Keep the prompt after a script has run

Sometimes running a script is only half the job: you also want to poke at the variables it left behind. Passing -i before the script runs that script and then enters interactive mode, so the session continues at the prompt with the script's state still in memory.

python -i inspect.py

A related form is a script name of -, which means the script itself is read from standard input. That still selects script execution; it does not add a prompt afterwards.

Keep the four roles apart: -c supplies statements, -m supplies a module, - supplies a script through standard input, and -i adds an interactive session once a script has finished.

See the arguments your program received

A program usually needs to know what it was asked to do. When they are known to the interpreter, the script name and the arguments after it are turned into a list of strings and assigned to the argv variable in the sys module. Import sys to reach that list:

import sys
print(sys.argv)

Two properties matter in practice. The elements are strings — nothing is converted to a number for you. And the list always has at least one element: when neither a script nor arguments are given, sys.argv[0] is an empty string rather than a missing value.

sys.argv is one ordinary list. Python does not create a separate global variable per argument, and this list is not the module search path.

Read the invocation form from sys.argv[0]

The first element does more than name a file: it tells the program how it was started.

There is a second rule that protects your program's own options. Anything found after the command supplied to -c, or after the module supplied to -m, is not consumed by the interpreter's option processing: it stays in sys.argv for that command or module to handle.

So python -m tools.report weekly --quiet gives the module a list whose first element is tools.report and whose remaining elements are weekly and --quiet. The --quiet flag is not stolen by the interpreter on the way through, which is exactly what lets a module define its own command-line interface.

Work at the interactive prompt

When commands are read from a terminal device, the interpreter is said to be in interactive mode. Before the first prompt it prints a welcome message stating its version number and a copyright notice, so the first thing on screen already tells you which interpreter you reached.

Two prompts then take turns:

Continuation lines are needed when you enter a multi-line construct. Typing an if statement shows both prompts at work:

>>> the_world_is_flat = True
>>> if the_world_is_flat:
...     print("Be careful not to fall off!")
...
Be careful not to fall off!

The construct kept asking for more input at the secondary prompt, and a blank line completed it. That blank line is how you tell the interpreter that a multi-line command entered interactively is finished, which is why nothing ran until it was typed.

Diagnose a prompt without line editing

Interpreter behavior can depend on installation and environment settings, and the interactive editing conveniences are among the parts that depend on system support. They are not guaranteed just because the prompt appeared.

There is a quick test. Type a word at the prompt, then press Left arrow. If the cursor moves, command-line editing is available. If nothing seems to happen, or a sequence such as ^[[D or ^B is printed on the line, command-line editing is not available, and only Backspace will remove characters from the current line.

That is an environment finding, not a program error. The session is still interactive and still runs your code; you simply edit the current line with Backspace until the environment offers more.

Declare a source encoding when the default is not enough

Python treats source files as encoded in UTF-8 by default. In that encoding, characters of most of the world's languages can be used at the same time in string literals, identifiers and comments — although the standard library uses only ASCII characters for identifiers, a convention that portable code should follow.

Two things outside Python have to cooperate for those characters to appear correctly: your editor must recognize that the file is UTF-8, and it must use a font that supports every character in the file. A file can be perfectly valid and still look like nonsense in the wrong editor.

To declare a codec other than the default, add a special comment line as the first line of the file:

# -*- coding: cp1252 -*-

There is one exception to that first-line rule. If the source starts with a Unix shebang line, the encoding declaration goes on the second line, immediately after it:

#!/usr/bin/env python3
# -*- coding: cp1252 -*-

The declaration is a comment line at the top of the file. It is not something you place at the end of the program or hide inside a string.

Key takeaways

• The input decides the mode: a terminal gives interactive execution, while a file name or a file supplied as standard input gives script execution.
• Three shortcuts, three jobs: -c runs quoted statements, -m locates a module and runs its source as a script, and -i before a script opens the prompt once that script finishes.
• sys.argv is a list of strings with at least one element, reached after import sys; its first element identifies the invocation — an empty string, a script name, -, -c, or a located module's full name.
• Your program keeps its own options: values after a -c command or a -m module stay in sys.argv instead of being consumed by the interpreter.
• The prompt speaks twice: >>> asks for a new command, ... asks for a continuation line, and a blank line completes a multi-line command.
• Source files are UTF-8 unless declared otherwise, with the declaration on the first line — or the second, after a shebang.