Plain Python functions, a fast Rust dataflow engine

---

You write a module of ordinary, typed functions. fnloom reads the graph straight from them: a function's name is a node, and its parameter names are the edges. Ask for the outputs you want, and fnloom runs exactly the functions needed to produce them, in a fixed order, with your mistakes caught before anything runs.

Highlights

• 🧵 Your functions are the graph. No decorators, no registration, no config objects. Delete fnloom tomorrow and your code is still plain Python you can call and test directly.
• ⚡ Up to 24× faster repeat runs than Hamilton on plain graphs. Compile a request once with prepare, then run it as often as you like. A 1,000-node graph runs in about 0.2 ms.
• 🛡️ Mistakes fail loudly, and early. A misspelled input, a dependency cycle, a type mismatch between two functions or an async def node in a sync build raises a clear error naming the culprit. Hamilton accepts several of these silently.
• 🎯 The same order, every run. Nodes run in topological order with ties broken by name, so logs and side effects never shuffle between runs.
• 🏔️ No depth limit. Nothing recurses over the graph, so a 50,000-node chain builds and runs. Hamilton hits RecursionError at around 1,000.
• 🦀 A Rust core you can embed. fnloom-core has no dependencies and no unsafe, and it doesn't care what a node runs.

A graph in one screen

# file: pricing.py
def total(price: float, quantity: int) -> float:
    """What the line costs before any discount."""
    return price * quantity


def discounted(total: float, discount: float = 0.0) -> float:
    """The total after the discount, if one is given."""
    return total * (1 - discount)


def label(discounted: float, currency: str = "EUR") -> str:
    """The price as shown to a customer."""
    return f"{discounted:.2f} {currency}"

That module is this graph. price and quantity aren't the name of any function, so they're inputs. discount and currency have defaults, so they're optional:

flowchart TD
    price([price]) --> total
    quantity([quantity]) --> total
    total --> discounted
    discount([discount?]) -.-> discounted
    discounted --> label
    currency([currency?]) -.-> label

Build a driver and ask for what you need:

import fnloom
import pricing

driver = fnloom.build(pricing)
driver.execute(["label"], inputs={"price": 2.5, "quantity": 4})
# -> {'label': '10.00 EUR'}

# Running the same request in a loop? Compile it once.
plan = driver.prepare(["label"], inputs={"price": 0.0, "quantity": 0})
plan.run(inputs={"price": 4.0, "quantity": 3})
# -> {'label': '12.00 EUR'}

Next, the guides cover which functions become nodes, overrides, prepared plans, type checks, lineage and every error message.

fnloom vs. Hamilton

fnloom uses Hamilton's model, so a module of Hamilton functions is already a module of fnloom nodes. The difference is in what happens when you run it.

	Hamilton 1.90.0	fnloom
A chain of 1,000+ nodes	RecursionError	✅ Runs at any depth
A dependency cycle	RecursionError when executed	✅ ValueError naming the cycle, at build
A misspelled input or override	Silently ignored	✅ ValueError naming it
An async def node	The un-awaited coroutine is the value	✅ ValueError at build(); build_async() awaits it
Execution order	Depends on how you list outputs	✅ Always the same
Running a request again	Re-planned on every call	✅ prepare once, run many times
Runtime dependencies	numpy, pandas and more	✅ None

Hamilton is fnloom's test oracle: the shared behaviour runs through both, and every deliberate difference is a row in the register. Most rows have a test that checks Hamilton and fnloom side by side. Moving over? Read Coming from Hamilton.

Performance

Milliseconds on an Apple M2 Pro, lower is better, from the full benchmarks:

Graph	Build (Hamilton → fnloom)	Repeat run (Hamilton → fnloom)
1,000 nodes, layered	21.6 → 7.2	4.35 → 0.21 (21×)
1,000-input fan-in	3.02 → 1.47	2.73 → 0.31 (9×)
10,000-node chain	207.5 → 63.4	RecursionError → 1.34
10,000 @parameterize rows	5,285 → 128	RecursionError → 1.35

Your node functions still run at Python speed. fnloom removes the overhead around them: planning, validation and dispatch.

Is fnloom a good fit?

Yes, if you compute many derived values from a few inputs (features, metrics, pricing, signals), want each step to be a small function you can test on its own, and run the same graph many times in one process.

Not yet, if you need dynamic execution, or an adapter that wraps how a node is called, such as GracefulErrorAdapter. They're on the roadmap. fnloom is also not a scheduler. It doesn't retry, distribute or schedule work, so pair it with an orchestrator if you need that.

Install

fnloom isn't on PyPI yet. Build it from source with Python 3.14 or newer, uv and a stable Rust toolchain:

git clone https://github.com/kelsayed17/fnloom.git
cd fnloom
uv sync
uv run maturin develop --release

Status

Pre-alpha. Done so far:

• ✅ The Rust core and the native Python path
• ✅ @parameterize and its sugar, @tag, @exclude, graph inspection, validate and type checks
• ✅ Graphs from plain functions, namespaces, rebuild(), and one driver shared between threads
• ✅ Result caching, in memory or on disk
• ✅ @config.when*, @extract_fields, @extract_columns, and an async driver that caches too
• ✅ Hooks before and after a run and each node, result builders, output checks and custom value checks
• ✅ Drawing as DOT or Mermaid text, export as JSON, and the fnloom command
• ✅ @check_output validators, steps, @inject, @resolve and node wrappers
• ✅ Namespaces with bind=, and a written recipe for each Hamilton feature left out
• 🔜 Dynamic execution

The design has the full plan. The name is provisional, pending a trademark check before the first release.

Contributing

CONTRIBUTING.md covers the setup and the one check script. Please report security problems privately, as SECURITY.md describes.

Licensed under Apache-2.0. Not affiliated with or endorsed by the Apache Software Foundation or the Apache Hamilton (incubating) project.