Frame the label file cleaner experiment

Success is not “I followed the tutorial.” Success is producing evidence that: UTF-8 lines become lowercase, de-duplicated labels in a new file; source untouched. The accepted input is narrow on purpose: a UTF-8 labels.txt that may contain blanks, duplicates, and mixed case. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: manual unique-lower count of the fixture before coding. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

from pathlib import Path
src=Path('labels.txt'); dst=Path('clean-labels.txt')
print({'source':str(src),'dest':str(dst),'overwrite_source':False})

Expected evidence: source and dest paths with overwrite false. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the label cleaner writing clean-labels.txt, a decorative win often looks like a clean run that never checks source byte-identical after run; clean file has unique lowercase lines. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: writing cleaned labels into a world-writable shared path or reading untrusted paths via ../.

For python-file-handling, write the claim on a sticky note in this exact shape: “Given a UTF-8 labels.txt that may contain blanks, duplicates, and mixed case, the label file cleaner will …”. Fill the ellipsis with the observable part of: UTF-8 lines become lowercase, de-duplicated labels in a new file; source untouched. Tape the baseline beside it: manual unique-lower count of the fixture before coding. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to normalize noisy training labels without destroying the source file. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (labels.txt with YES/yes/No/blank lines) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against labels.txt with YES/yes/No/blank lines. Note the metric you will eventually require (source byte-identical after run; clean file has unique lowercase lines) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is FileNotFoundError, encoding errors, or accidental overwrite of the source.

At the experiment brief 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 a falsifiable claim and baseline written before coding 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

Next