Debug FileNotFoundError in the label file cleaner

Do not start with a speculative fix for the label file cleaner. Force the failure on purpose, save the before output, then change one cause at a time. Retries are allowed only for transient conditions—not for bad input that will fail forever on python-file-handling.

from pathlib import Path
try:
    Path('missing-labels.txt').read_text(encoding='utf-8')
except FileNotFoundError as e:
    print('caught', type(e).__name__)

Expected evidence: caught FileNotFoundError. If you cannot reproduce on demand, you do not yet control the failure mode for python-file-handling.

After repair, rerun the exact reproduction command. Keep the failing fixture as a regression seed for the observability page. For the label cleaner writing clean-labels.txt, remember the claim you are restoring: UTF-8 lines become lowercase, de-duplicated labels in a new file; source untouched.

Store a one-command reproduction for: FileNotFoundError, encoding errors, or accidental overwrite of the source. The command should use labels.txt with YES/yes/No/blank lines or a minimal mutant of it. Paste the failing output into notes/failure-before.txt (or your shell scrollback as copied text). After the fix, paste notes/failure-after.txt and keep both.

Retries belong only on transient faults. If the failure is bad input, a bad allowlist, or a logic bug in the label file cleaner, retrying will amplify cost without repairing trust around normalize noisy training labels without destroying the source file.

Classify the failure as prevent, detect, contain, or recover—using this lab’s language, not a generic poster. For python-file-handling, the first fix should usually be detect+prevent at the boundary, because FileNotFoundError, encoding errors, or accidental overwrite of the source is cheaper to stop early than to explain in production prose.

At the debugging stage for python-file-handling, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about labels.txt with YES/yes/No/blank lines that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: manual unique-lower count of the fixture before coding.

For this page specifically, success looks like before/after evidence for the characteristic failure while still centering the user decision to normalize noisy training labels without destroying the source file. If you cannot point to a file, command, or assertion that proves that for the label file cleaner, stay on this page instead of advancing.

ML Python starter

Previous · Next