Course Guide¶

Guide Fit¶

flowchart TD
  family["Python Programming"] --> program["Python Functional Programming"]
  program --> pressure["A concrete learner or reviewer question"]
  pressure --> guide["Course Guide"]
  guide --> next["Modules, capstone, and reference surfaces"]

flowchart TD
  question["Name the exact question you need answered"] --> skim["Skim only the sections that match that pressure"]
  skim --> crosscheck["Open the linked module, proof surface, or capstone route"]
  crosscheck --> next_move["Leave with one next decision, page, or command"]

Read the first diagram as a timing map: this guide explains the course spine, not every support page in equal detail. Read the second diagram as the guide loop: arrive with one question about sequence or scope, then leave knowing which arc, proof surface, or capstone route to open next.

This guide explains how the course is shaped and why the sequence matters. The course is not a pile of functional programming topics. It is a route from local reasoning to systems that remain testable and reviewable under operational pressure.

Choose the right surface¶

If you need...	Best page
the shortest entry route	Start Here
the promise and evidence route for one module	Module Promise Map
the sequence justified	Module Dependency Map
an honest bar for moving on	Module Checkpoints
the capstone route kept explicit	FuncPipe Capstone Guide and Capstone Map
the proof route from claim to evidence	Proof Matrix

The Four Arcs¶

Purity and dataflow¶

Modules 01 to 03 establish the semantic floor:

what purity really buys you
how data-first APIs change refactoring pressure
how lazy pipelines remain understandable without hidden execution

Without this floor, later abstractions feel clever instead of necessary.

Failure and modelling¶

Modules 04 to 06 turn pipelines into something survivable:

failures become typed values instead of scattered exception paths
domain states and validations become explicit shapes
chained flows keep context visible instead of implicit

Effects and async pressure¶

Modules 07 to 08 move the course from local transforms to real systems:

capabilities, ports, and adapters define what effectful code may do
retries, resources, and transactions become reviewable policy choices
async work gains explicit pressure-control and testable boundaries

Interop and sustainment¶

Modules 09 to 10 ask whether the design can survive a team and a production lifecycle:

can the functional core coexist with normal Python libraries
can performance and observability be improved without blurring boundaries
can the codebase evolve without turning the functional vocabulary into ceremony

What each arc should unlock¶

Arc	What should feel more possible after it	Best capstone mirror
Modules 01 to 03	separating pure transforms, explicit configuration, and lazy execution	`fp/`, `result/`, `streaming/`, pipeline core
Modules 04 to 06	modelling failure and context without hiding control flow	result containers, validations, configured flows
Modules 07 to 08	drawing effect boundaries and surviving async pressure honestly	capabilities, adapters, async coordination layers
Modules 09 to 10	evolving the system without dissolving its contracts	interop surfaces, proof routes, review surfaces

How The Capstone Fits¶

Modules 01 to 03 explain the capstone's pure helpers, configuration shapes, and stream stages.
Modules 04 to 06 explain its failure containers, modelling choices, and compositional pipeline style.
Modules 07 to 08 explain its shells, adapters, policies, and async coordination layers.
Modules 09 to 10 explain its interop surfaces, review workflow, and sustainment story.

Use these pages at the right moment¶

Moment	Best page
before you start Module 01	Learning Contract
when a module title sounds familiar but the promise is fuzzy	Module Promise Map
when your pressure is concrete and engineering-shaped	Engineering Question Map
when you want the rehearsal loop in one place	Practice Map
when you need executable proof	Proof Matrix
when you need generated history comparisons	History Guide

Honest Expectation¶

If you rush, the course will feel heavier than necessary. If you read it in order and keep the capstone in view, the later modules should feel like consequences of earlier boundary decisions instead of unrelated advanced techniques.

Stop here when¶

you know which arc you are entering next
you know which support page owns your current pressure
you can name the capstone mirror for the current module range