March 19, 2026
Run it anywhere? Brace for everywhere
What if Python was natively distributable?
Python that “just runs anywhere”? Devs are split between “finally!” and “not this again”
TLDR: A new project promises Python code that runs on other machines as simply as a normal function call, without heavy setup. The community erupted: some love the simplicity, while others warn it repeats old mistakes—performance is unpredictable, security is risky, and you can’t hide the network, which makes this debate matter.
A Python dev dreams of hitting “run” and having a function execute on another machine with zero fuss — no flowcharts, no server babysitting, no hoops. The author’s pitch: keep Python’s normal behavior, just add a simple “run this over there,” and that’s what his new project, Wool, aims to do. Sounds clean. The internet, however, reached for popcorn.
Skeptics rolled in first, waving the classic “you can’t hide the network” banner and citing the “distributed object fallacy” with a pointed Martin Fowler link. Another camp accused the repo of quietly rebuilding the very “mini operating system” it dissed — the drama of “you became the thing you swore to destroy” wrote itself. Performance worriers piled on: turning a simple function call into a long-distance trip means unpredictable delays and a lot of observability (aka tools to see what’s happening) you didn’t plan for. Security hawks went full red alert about sending code around, warning of remote code execution if serialization gets sketchy.
And because it’s the internet, someone pitched “What if… we did this in Lua?” and the thread briefly morphed into a comedy special. Memes flew — “You wanted to run a function, you got an OS” became the catchphrase, alongside quips like “Wool pulls the wool over our eyes.” Team Hopeful wants less ceremony; Team Reality says physics and failures don’t care. Popcorn status: refilled.
Key Points
- •The article argues that Python frameworks often conflate distributed execution with orchestration, complicating simple remote function calls.
- •Common requirements in existing tools (DAGs, state backends, serializers, message brokers, retries) impose constraints unrelated to basic execution.
- •Embedding orchestration into execution primitives leads to “framework code,” constraining function shapes, serialization, control flow, and error handling.
- •The author proposes preserving Python’s native semantics—async/await, async generators, exceptions, context variables—across machines.
- •The author introduces “Wool,” aiming to make Python execution distributable without enforcing orchestration or changing semantics.