Day 11: Exceptions and isolated environments

Clause trace. notes.txt absent: open() raises FileNotFoundError, so except runs, else is skipped, finally runs:

cannot open notes.txt
cleanup

notes.txt present: try succeeds, except is skipped, else runs (and closes f), finally runs:

opened notes.txt
cleanup

With-based rewrite (save as with_version.py and run it in the same two states):

def show(path):
    try:
        with open(path, encoding="utf-8") as f:
            print("opened", f.name)
    except FileNotFoundError as e:
        print("cannot open", e.filename)
        return
    print("closed after with:", f.closed)
show("notes.txt")

notes.txt present:

opened notes.txt
closed after with: True

notes.txt absent:

cannot open notes.txt

The with statement closes the file whenever its block exits, normally or through an exception, so neither the manual close() nor a finally clause is needed for the file. The except stays outside the with because open() itself is what raises.
Two things a bare except: hides: (1) KeyboardInterrupt (Ctrl+C) and SystemExit, because a bare except catches every BaseException; (2) programming errors such as a NameError from a typo. Demonstration:

try:
    prnt("hi")
except:
    print("something went wrong")

something went wrong

The misspelled print raised NameError, and the bare except reported it as a vague failure. With except FileNotFoundError the same typo would surface as a NameError traceback pointing at the bad line.

Observed: python3 clinic.py exits with status 1. The last traceback line is:

ValueError: invalid literal for int() with base 10: 'x9'

and the frame above it points at clinic.py line 5, total += int(raw). Diagnosis: fault line = the int(raw) call while reading data line 2 (bo,x9); exception type = ValueError; narrowest fix = wrap only int(raw) in try/except ValueError, record lineno in skipped, and continue. Fixed clinic.py:

total = 0
skipped = []
with open("scores.csv", encoding="utf-8") as fh:
    for lineno, line in enumerate(fh, start=1):
        name, raw = line.strip().split(",")
        try:
            value = int(raw)
        except ValueError:
            skipped.append(lineno)
            continue
        total += value
print("total", total, "skipped", skipped)

total 12 skipped [2]

Why ValueError is the narrowest correct choice: inspect the hierarchy.

print([c.__name__ for c in ValueError.__mro__])

['ValueError', 'Exception', 'BaseException', 'object']

int() reports a bad literal with ValueError itself, so nothing narrower exists for this failure. Its parent Exception would also swallow unrelated bugs (a NameError from a typo, a TypeError) and misreport them as bad data. The try covers only int(raw): a failing open() or a row with the wrong number of fields still raises loudly instead of being counted as skipped.

Step 1: two different paths. The first is whatever python3 resolves to on your machine (for example /usr/bin/python3, or another environment's python), never inside $work; the second is $work/.venv/bin/python. Different paths prove two different interpreters.
Step 2: exit status 1; the last line is:

ModuleNotFoundError: No module named 'day11_helper'

Step 3:

helper from the venv

Step 4: exit status 1 again, with the same last line:

ModuleNotFoundError: No module named 'day11_helper'

The same import fails, succeeds, then fails depending only on which interpreter runs it, so this is an environment fault: install the module into the interpreter you run (step 3) or run the interpreter that has it. Editing the import line is the wrong fix.
Step 5:

include-system-site-packages = false
True

and the pip check exits with status 1 and an error ending in No module named pip, because the venv was created with --without-pip.
Why the venv cannot see the system site-packages: pyvenv.cfg sets include-system-site-packages = false, and sys.prefix != sys.base_prefix shows the venv uses its own prefix, so its sys.path contains only its own site-packages folder. The reverse also holds: python3 never searches $work/.venv, which is why step 4 failed.
Step 6:

packaging==24.1

A pinned line records the exact version; installing it later would use .venv/bin/python -m pip install -r requirements.txt in a venv created with pip, with access to a package index.

Reproduce both runs:

good/bin/python report.py

report ok

.venv/bin/python report.py

exits with status 1; the last line is:

ModuleNotFoundError: No module named 'day11_helper'

Evidence from both interpreters:

for py in good/bin/python .venv/bin/python; do
    "$py" -c "import sys, importlib.util; print(sys.executable); print(importlib.util.find_spec('day11_helper') is not None)"
done

prints four lines: $work/good/bin/python, True, $work/.venv/bin/python, False. Diagnosis: environment fault. report.py and its import are correct; the interpreter in .venv lacks the dependency. Minimal fix: install the dependency into .venv (here, copying the one-file module into the venv's purelib is the install). Running good/bin/python report.py also works, but it leaves .venv broken, so it does not meet Task 1:

good_site=$(good/bin/python -c "import sysconfig; print(sysconfig.get_path('purelib'))")
venv_site=$(.venv/bin/python -c "import sysconfig; print(sysconfig.get_path('purelib'))")
cp "$good_site/day11_helper.py" "$venv_site/"
.venv/bin/python report.py

report ok

Editing the import (deleting it, or wrapping it in try/except ImportError) is the wrong fix: it hides the missing dependency instead of providing it.
File task:

def read_text(path):
    try:
        with open(path, encoding="utf-8") as fh:
            return fh.read()
    except FileNotFoundError as e:
        print("missing", e.filename)
        return None
print(read_text("no_such_file.txt"))

missing no_such_file.txt
None