Module 01: Purity, Substitution, and Local Reasoning¶

Module Position¶

flowchart TD
  family["Python Programming"] --> program["Python Functional Programming"]
  program --> module["Module 01: Purity, Substitution, and Local Reasoning"]
  module --> lessons["Lesson pages and worked examples"]
  module --> checkpoints["Exercises and closing criteria"]
  module --> capstone["Related capstone evidence"]

flowchart TD
  purpose["Start with the module purpose and main questions"] --> lesson_map["Use the lesson map to choose reading order"]
  lesson_map --> study["Read the lessons and examples with one review question in mind"]
  study --> proof["Test the idea with exercises and capstone checkpoints"]
  proof --> close["Move on only when the closing criteria feel concrete"]

Read the first diagram as a placement map: this page sits between the course promise, the lesson pages listed below, and the capstone surfaces that pressure-test the module. Read the second diagram as the study route for this page, so the diagrams point you toward the Lesson map, Exercises, and Closing criteria instead of acting like decoration.

Keep These Pages Open¶

Use these support surfaces while reading so the semantic floor stays attached to the course promise and the capstone proof route:

First-Contact Map for the shortest stable entry route
Module Promise Map for the plain-language contract of the module
Module Checkpoints for the exit bar before Module 02
Capstone Map for the matching core packages and proof surfaces

Carry this question into the module:

Which code can still be trusted as a local transform, and what immediately stops being substitutable once hidden state or effects enter?

This module establishes the semantic floor for the whole course. If the learner cannot separate pure transforms from hidden state here, every later abstraction will feel ornamental instead of necessary.

Learning outcomes¶

how purity and substitution change the way you review Python code
how immutability and value semantics reduce hidden coupling
how small composable transforms make testing and refactoring cheaper
how to judge whether a rewrite preserves behavior instead of only reshaping syntax

Lesson map¶

Exercises¶

Take one helper from the capstone and classify it as pure, effectful, or mixed, then justify the classification in terms of substitution.
Rewrite one small imperative branch as a value-preserving transform and state what behavioral evidence would prove the refactor safe.
Pick one input transformation and explain whether repeated application is idempotent, conditional, or unsafe.

Capstone checkpoints¶

Identify which helpers in FuncPipe stay pure across refactors.
Trace where configuration is explicit instead of ambient.
Check whether tests prove behavior or only exercise examples.

Before moving on¶

You should be able to explain why a function is pure, why that matters for substitution, and where a thin effect wrapper belongs when purity is impossible. Use Refactoring Guide and compare against capstone/_history/worktrees/module-01 before moving forward.

Closing criteria¶

You can defend a purity judgment without appealing to taste or syntax alone.
You can point to the exact place where an effect wrapper belongs when the transform itself cannot stay pure.
You can compare two implementations and explain whether they are meaning-preserving under substitution.

Directory glossary¶

Use Glossary when you want the recurring language in this module kept stable while you move between lessons, exercises, and capstone checkpoints.