Build brief · Python
Replace scattered print statements with logs that explain one batch job without exposing secrets.
Start with the business or technical outcome
Good logs tell an operator what happened, where and with which safe context; they do not dump every variable. This field lab turns the topic into a small deliverable that can be built, checked and explained. A CSV import script processes customer-like synthetic records, skips invalid rows and needs a concise success summary plus diagnosable failures.
Use synthetic records only. Decide who reads each output: a learner at the console, an operator checking a file and a developer investigating an exception. Logging level and context should serve those readers.
Never log passwords, tokens or full personal data. Redaction and field selection belong in the design, not as cleanup after logs have already been written.
What to understand before opening the tool
Understand module-level loggers, DEBUG through CRITICAL levels, handlers, formatters, propagation, exception information, rotation, configuration and contextual fields. The root logger can surprise larger applications if configured carelessly.
Logs are not metrics or traces, although observability tools can connect them. Use a stable event message or fields where machine analysis matters.
logging Logger
Use it for: emit levelled events from each module Keep as evidence: named logger behavior
Handlers
Use it for: route records to console and rotating file destinations Keep as evidence: handler configuration
Formatter or Adapter
Use it for: add timestamp, level, module and safe job context Keep as evidence: consistent event shape
pytest or unittest
Use it for: capture and assert important logging behavior Keep as evidence: tests without brittle full-string matching
The practical outcome is a small Python importer with configured console and rotating-file handlers, structured context, tests and sample troubleshooting transcript. Build it with fictional, public or explicitly authorised data. Record the starting state before making changes, because a screenshot of the final screen cannot explain how the result was produced. The strongest evidence is a short chain: requirement, action, validation and one reflection on what you would improve.
Build the workflow in six controlled moves
Start from operator questions, then add only the events needed to answer them.
- Define logging questionsList startup, progress, invalid input, external failure and completion events.Checkpoint: Event catalogue with level.
- Create module loggersUse __name__ and avoid configuring handlers in every imported module.Checkpoint: Clean logger hierarchy.
- Configure destinationsSend concise INFO output to console and appropriate detail to rotating files.Checkpoint: Configuration and rotation test.
- Add safe contextAttach job ID, file name and row reference without sensitive payloads.Checkpoint: Correlated sample log.
- Log exceptions correctlyCapture stack information at the boundary that can act or terminate.Checkpoint: One controlled failure transcript.
- Test and review privacyAssert key warning or error events and scan samples for secret-like data.Checkpoint: Automated tests and privacy checklist.
Do not rush through the successful path. Repeat one step with a controlled variation and compare the evidence. That second run reveals which inputs are important and gives you a concrete troubleshooting story for interviews.
Tools, decisions and proof
Choose level according to actionability, not according to how dramatic a message sounds.
| Decision or signal | Action to take | Evidence to retain |
|---|---|---|
| DEBUG | Detailed developer context disabled in normal runs | Parser branch or timing detail |
| INFO | Expected lifecycle milestone | Job start, count and successful completion |
| WARNING | Recoverable anomaly needing review | Skipped malformed row |
| ERROR | Operation failed but process may continue or exit cleanly | Unreadable input or dependency failure |
| CRITICAL | Rare application-wide inability to continue safely | Unrecoverable initialization failure |
Failure tests that improve the project
More log volume does not automatically create better diagnostics.
- Using print for operational events: Print lacks consistent levels, routing and context.
- Calling basicConfig inside libraries: Applications should own overall logging configuration.
- Logging an exception at every layer: Duplicate stacks create noise; log where responsibility is clear.
- Building messages with secrets: Select safe fields and redact at source.
- Asserting exact timestamps in tests: Test event level and meaning without brittle dynamic text.
Turn the exercise into credible portfolio evidence
Publish the importer, fictional CSV, configuration and a short log-reading exercise. Show how job ID connects start, warning and completion events.
Add a before-and-after comparison with print statements, but explain the operational difference instead of claiming logging makes code automatically reliable.
Explain it clearly in an interview
Explain logger hierarchy, why handlers belong at the application boundary, how you select levels and where exception logging should occur.
Peer review before calling the work complete
Ask another learner to inspect the result without watching you build it. Give them the original scenario—a CSV import script processes customer-like synthetic records, skips invalid rows and needs a concise success summary plus diagnosable failures.—and the evidence pack, but not your intended conclusion. They should be able to trace the input, identify the main decision and locate the proof of the output. If they cannot, improve the labels, timestamps or explanation instead of adding decorative screenshots.
Use this acceptance condition during the review: A normal run is readable, one invalid row is visible without stopping the batch, one fatal error has stack context, rotation works and samples contain no sensitive values. Record one question the reviewer raised and the change you made in response. That small feedback loop makes the Python logging project exercise more credible, easier to maintain and easier to explain under interview questioning.
Questions learners ask
Why use __name__ for a logger?
It creates a hierarchy aligned with modules and lets applications configure groups consistently.
Should every exception be logged?
No. Log where the program handles, translates or terminates it; otherwise duplicate records can appear.
What is log rotation?
It limits and archives file output according to size or time policy so logs do not grow forever.
Are structured logs always JSON?
No. Structure means consistent machine-usable fields; JSON is one common representation.
Use current product guidance
Menus, fields, permissions and service behavior can change between product versions or tenant configurations. Check the official Python documentation before applying version-sensitive steps in a live environment.
Build the complete skill path
Learn Python syntax, data structures, functions, OOP, files, databases, testing, debugging and automation by building small, explainable applications.
Final perspective
The real value of Python logging project is the ability to complete a controlled task and defend the result with evidence. A learner who can show the input, explain the decision, verify the output and describe one realistic exception demonstrates far more than someone who has only memorised a menu path or definition.