REPL and scripts

What you will be able to do

• Start and leave the Python REPL
• Run a .py file with python3 and read its exit status
• Choose script vs one-liner for a given task

Why this matters for data work

You will poke at a value in the REPL (read–eval–print loop) and ship behavior as a script. Jobs, CI, and containers all run files: python extract.py. Knowing both modes keeps exploration short and production boring.

Concepts

REPL — start with python3 and no filename. You type expressions; Python prints results. Exit with exit() or Ctrl-D.

Script — a .py file. Python runs it top to bottom. Print only what you need; return status matters in shells (echo $?).

One-liner — python3 -c "code" for a single check. Fine for smoke tests; not for pipelines.

Exit code — 0 means success. A traceback usually ends non-zero. Schedulers key off that.

Practice on your machine

cd ~/dcubes/python-lab

REPL

python3

At the >>> prompt:

>>> 2 + 2
4
>>> print("lab")
lab
>>> exit()

Script

cat > greeter.py << 'EOF'
import sys

name = sys.argv[1] if len(sys.argv) > 1 else "world"
print(f"hello, {name}")
EOF
python3 greeter.py
python3 greeter.py dcubes

hello, world
hello, dcubes

Exit status

python3 greeter.py
echo $?

0

A failing script:

cat > fail.py << 'EOF'
raise SystemExit("boom")
EOF
python3 fail.py
echo $?

Non-zero status (often 1). Schedulers treat that as failure.

One-liner smoke test

python3 -c "import sys; print(sys.version.split()[0])"

What you should see

• REPL shows >>> and evaluates each line.
• greeter.py prints a greeting; with an argument it uses that name.
• Successful runs end with exit code 0.

Common mistakes

• Leaving the REPL open and pasting multi-file lessons into it. Use files for anything longer than a few lines.
• Assuming print failure is enough. Check echo $? when debugging jobs.
• python vs python3. Stay consistent with Getting Started.

Next

Virtualenvs and pip