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: 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.
This page keeps the report’s place in the series and points 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¶
A design that lives with the code is read by the people who use the code, and it stays checked against it. The report 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); what is missing is dumping a pipeline built in Python.
The shipped surface is Report 2, which now points to pipekit’s tour of the core.