HumachLearnLearn · explore · apply
Start learning
Object-Oriented Python · Lesson 156

Separate Pure Logic from I O

Pure logic receives values and returns values without reading files, printing, prompting users or depending on hidden mutable state.

ConceptWorked examplePracticeKnowledge check
Textbook walkthrough

Separate Pure Logic from I O

Pure logic receives values and returns values without reading files, printing, prompting users or depending on hidden mutable state. Separating this logic from input/output code makes calculations easier to test and reuse because tests can supply ordinary values instead of reproducing files, terminals or network calls.

Learning goal: explain why Separate Pure Logic from I O behaves this way, apply it to a small example, and verify the result independently. Begin by being able to justify this first step: Put parsing/file/user interaction at the boundary.

Deeper walkthrough

Read Separate Pure Logic from I O as a mechanism, not a recipe

Treat this as a sequence of observable decisions rather than one opaque command. Stage 1: Put parsing/file/user interaction at the boundary. Stage 2: Pass clean values into calculation functions. Stage 3: Return results instead of printing from the core logic. Final checkpoint: Test the pure function with normal and edge-case inputs.

Mechanism

Follow the transformation

Put parsing/file/user interaction at the boundary.

Pass clean values into calculation functions.

Return results instead of printing from the core logic.

Evidence

Know what would convince you

  • Trace a tiny input by hand and compare the runtime result.
  • Inspect type, value/shape and any mutation/side effect explicitly.
Useful distinctionInput: Objects/values supplied to the operation.
How it works

Trace the mechanism step by step

  1. Put parsing/file/user interaction at the boundary.
  2. Pass clean values into calculation functions.
  3. Return results instead of printing from the core logic.
  4. Keep formatting/export in a separate boundary function.
  5. Test the pure function with normal and edge-case inputs.
Worked demonstration

Pure calculation vs output

# Step 1 — Define the reusable `mean` function; its indented body describes what happens for each call.
def mean(values):
    # Step 2 — Return the computed value to the caller so the result can be reused or tested.
    return sum(values) / len(values)

# Step 3 — Compute the right-hand expression and store its result in `result` for the next step.
result = mean([2, 4, 6])
# Step 4 — Display the current value explicitly so the result/state can be inspected during execution.
print(f"mean={result:.1f}")
Expected / illustrative result
mean() contains only the calculation; print() is an I/O concern in the calling layer.
Interpret the result.

For Separate Pure Logic from I O, trace the specific input through the mechanism above and independently verify one returned value, state change or side effect.

Distinctions & related ideas

Place the concept correctly

InputObjects/values supplied to the operation.
StateNames or mutable objects that may change during execution.
OutputReturned value, side effect, file, plot or exception to inspect.
Use deliberately

When it is appropriate

Use Separate Pure Logic from I O when it answers a defined question in Object-Oriented Python and its inputs/assumptions match the current data or program state.

Boundary conditions

When to stop or reconsider

Reconsider Separate Pure Logic from I O when the required information is unavailable, the operation would violate a validation/data boundary, or a simpler operation answers the question more transparently.

Common mistakes

Failure modes to recognise

  • Running the operation on the wrong object/type or in the wrong environment.
  • Inferring correctness from “no exception” without checking the produced value/state.
  • Hiding a boundary case instead of making its behaviour explicit.
Verification

How to check the result

  • Trace a tiny input by hand and compare the runtime result.
  • Inspect type, value/shape and any mutation/side effect explicitly.
  • Run an edge or invalid case and confirm the exception/behaviour is deliberate.
Hands-on practice

Demonstrate understanding

Try this:

Construct a tiny example of Separate Pure Logic from I O. First put parsing/file/user interaction at the boundary. Then pass clean values into calculation functions. Predict the result before execution and explain one boundary or failure case.

Use the smallest values that expose the language rule. Write the expected value and type first, then compare the actual state/output with that prediction.
Knowledge check

Check reasoning, not memorisation

Which approach best demonstrates understanding of Separate Pure Logic from I O?

Quick reference

Remember the logic

Step 1Put parsing/file/user interaction at the boundary.
Step 2Pass clean values into calculation functions.
Step 3Return results instead of printing from the core logic.
Step 4Keep formatting/export in a separate boundary function.
Lesson summary

What to remember

  • Pure logic receives values and returns values without reading files, printing, prompting users or depending on hidden mutable state. Separating this logic from input/output code makes calculations easier to test and reuse because tests can supply ordinary values instead of reproducing files, terminals or network calls.
  • Put parsing/file/user interaction at the boundary.
  • Running the operation on the wrong object/type or in the wrong environment.
  • Trace a tiny input by hand and compare the runtime result.