toolz primer
Report 1 · Where pipekit comes from, and why its operators are classes
Abstract¶
This report now lives in pipekit’s own documentation, as its Background page. It covers where pipekit comes from, what it inherits from toolz, the six things plain functions cannot carry, and why operators settled on a typed base class while the data flowing through them did not. We keep this page only to hold the report’s place in the series and to point to the sections.
About this report
| Status | Moved to pipekit’s docs; this page is a pointer |
| Audience | anyone reviewing the pipekit design before the structural reports |
| Companions | Report 2 (pipekit’s shipped surface), Report 3 (sister libraries), Report 9 (use cases) |
| Checked against | toolz 1.2.0 and pipekit 0.0.2 (ef3c17f), when it moved |
Where each section went¶
We moved the report because a design that lives with the code is read by the people who use the code, and it stays checked against it. It moved whole, with its examples, tables and figures, in MkDocs syntax (Table 1).
Table 1:The report’s sections and their new homes on pipekit’s Background page.
| Section here | On the Background page |
|---|---|
| Why this report exists | Why this page exists |
| toolz as the ancestor, and the one-to-one mapping to pipekit | toolz as the ancestor |
| Where toolz stops being enough (the six gaps) | Where toolz stops being enough |
| The trajectory: functions, Protocols, typed entities | The trajectory |
| Why typed operators are not over-engineering | Why typed operators are not over-engineering |
| Where next | Where next |
One correction travelled with it. Nested pipelines can be loaded from hand-written Hydra YAML today (HydraConfigLoader.from_yaml in pipekit-experiment), whereas what is missing is dumping a pipeline built in Python.
We cover the shipped surface in Report 2, which now points to pipekit’s tour of the core.