---
title: 'zerodep: Evaluating Python’s Stdlib-Only Ecosystem'
url: https://www.emergentmind.com/topics/zerodep
type: topic
---

# zerodep: Evaluating Python’s Stdlib-Only Ecosystem

zerodep is a software project and an empirical testbed for evaluating how much of Python’s third-party utility ecosystem can be reproduced using only the standard library, and at what correctness and performance cost [2605.21405]. It is organized as a growing collection of single-file Python modules, each intended as a stdlib-only reimplementation of a popular third-party library, developed with LLM assistance under strict constraints: no external imports, single file, drop-in API compatibility, and mandatory correctness validation against a reference library [2605.21405]. The project is framed as a response to dependency bloat, supply-chain risk, and deployment friction in constrained environments, while explicitly not being presented as a replacement for all third-party software or for domains whose value depends on native code acceleration, such as NumPy, PyTorch, or heavy media processing [2605.21405].

## 1. Definition and design constraints

At its core, zerodep consists of stdlib-only modules that reimplement the API of established Python packages while remaining directly embeddable into a codebase with no runtime dependencies [2605.21405]. The project is positioned as a disciplined alternative to ad hoc vendoring: instead of copying a small utility into an application without systematic maintenance, zerodep offers curated, versioned, tested modules that can be embedded directly into projects [2605.21405].

The constraints define the project rather than merely constraining it. Every module must be stdlib-only; the entire implementation must live in one `.py` file; no external imports are allowed in module source beyond the standard library; the target is drop-in API compatibility with an existing library such as `yaml`, `httpx`, `tenacity`, or `pydantic`; acceptance requires mandatory correctness validation against a reference library; and development proceeds through an LLM-assisted workflow with automated behavioral comparison against the reference implementation [2605.21405].

This scope places zerodep between two established poles in Python software engineering. Relative to the standard library, it demonstrates what can be built on top of stdlib primitives through focused wrapper design or reimplementation. Relative to third-party packages, it attempts to preserve familiar APIs while eliminating packaging dependencies [2605.21405]. The intended target is the large middle ground of utility and infrastructure libraries: parsers, serializers, HTTP clients, retry decorators, config loaders, schedulers, simple protocol stacks, and similar building blocks [2605.21405].

## 2. Corpus, categories, and complexity structure

The paper reports 44 modules across 12 categories and three complexity tiers [2605.21405]. The categories are network, protocol, serialization, validation, text, config, terminal, crypto, image, process, storage, and devtools [2605.21405]. The tiers are defined as simple, medium, and subsystem: simple modules are narrow utilities, often under 200 LOC; medium modules are multi-concern modules, roughly 200–800 LOC; subsystem modules are protocol or systems modules, often over 800 LOC [2605.21405].

Representative modules include `yaml` versus PyYAML, `httpclient` versus httpx, `retry` versus tenacity, `validate` versus pydantic, `soup` versus BeautifulSoup4, `protobuf` versus google-protobuf, `png` versus Pillow, `aes` versus PyCryptodome, `scheduler` versus croniter/APScheduler, `jsonc` versus commentjson, and protocol modules such as `a2a` and `acp` [2605.21405]. Several subsystem modules are large by single-file standards: `httpclient` is 2,592 LOC, `protobuf` 2,453 LOC, `a2a` 2,204 LOC, and `acp` 2,337 LOC [2605.21405].

The evaluation is organized around two research questions. The first asks where stdlib suffices: for which categories and complexity tiers can a stdlib-only implementation replace a popular package without meaningful loss in correctness or performance. The second asks how effective LLM-assisted constrained generation is when code must be stdlib-only, single-file, and behaviorally matched to an existing library [2605.21405].

The resulting corpus functions as a controlled benchmark for delineating a stdlib capability boundary. The paper’s structure suggests that zerodep is intended not only as a collection of modules, but also as an empirical instrument for characterizing which library functions are fundamentally packaging conveniences, which are abstractions over standard-library primitives, and which depend materially on compiled implementations [2605.21405].

## 3. Correctness validation and benchmarking protocol

Correctness evaluation is based on dedicated test suites that compare each zerodep module directly against its reference library on shared inputs [2605.21405]. These suites cover “hundreds of test vectors” across normal use, edge cases, malformed inputs, and format-specific corner cases such as YAML null spellings, JSON comment placement, and protobuf field ordering [2605.21405]. API compatibility is therefore assessed behaviorally rather than nominally: the same calls are issued to both implementations and outputs are compared for equality [2605.21405].

The paper notes that some modules intentionally omit rare or deprecated features, and that these omissions are documented explicitly in the module docstrings [2605.21405]. This makes correctness a statement about the chosen API surface rather than total equivalence. An important implementation detail arises when zerodep modules share names with their references, such as `yaml.py` versus the PyYAML package. To avoid interference, the tests manipulate `sys.path` and `sys.modules` so that both implementations can be loaded in the same process [2605.21405]. The reference libraries are pinned in a conda environment, and all 44 modules passed their correctness suites [2605.21405].

Performance evaluation uses `pytest-benchmark` with its default statistical procedure [2605.21405]. Each benchmark contains two methods, one for zerodep and one for the reference implementation, using identical inputs under the same environment [2605.21405]. The reported metrics are mean time per operation and derived operations per second, all obtained on a single Linux machine with Python 3.12 [2605.21405]. Results are serialized to JSON and processed into a dashboard, while benchmarks and tests run automatically in GitHub Actions [2605.21405].

The paper defines the performance ratio as

$$
r = \frac{t_{\mathrm{ref}}}{t_{\mathrm{zerodep}}}.
$$

Parity is defined as $r \in [0.5, 2.0]$, meaning the zerodep implementation is no more than $2\times$ slower and no more than $2\times$ faster than the reference; faster means $r > 2.0$; slower means $r < 0.5$ [2605.21405]. The threshold is justified pragmatically: for many I/O-bound utility libraries, a microsecond-level factor of two is negligible relative to network or disk latency [2605.21405].

## 4. Empirical results and the stdlib capability boundary

The aggregate outcome is mixed in a structured way. The authors report that roughly two-thirds of the modules achieve parity, and that many exceed it; in the detailed breakdown across 44 modules, 19 are consistently faster, 11 achieve parity, 6 are consistently slower, and the remainder are mixed across operations [2605.21405]. This distribution is central to the project’s significance because it rejects both extreme positions: neither “stdlib is enough for everything” nor “third-party packages are always necessary” fits the data.

Several categories exhibit large speedups. Reported examples include `jsonc` versus `commentjson` at 75–115x faster, `httpclient` versus `httpx` sync at 18–32x faster, `httpclient` versus `httpx` async at 20–26x faster, `jsonrpc` versus `jsonrpcserver` at 10–14x faster, `retry` versus `tenacity` at 37x faster in decorator overhead, `scheduler` versus `croniter` at 5–10x faster, `yaml` versus PyYAML’s default pure-Python path at 6–7x faster, `soup` versus BeautifulSoup4 at 2.1–3.3x faster, and `tabulate` versus tabulate at 3–4.5x faster [2605.21405].

The explanation offered is architectural rather than ideological. These gains arise from avoiding plugin systems, transport abstractions, schema caches, middleware layers, generic dispatch frameworks, and intermediate representations [2605.21405]. The zerodep modules are narrower and often target the common case directly. `jsonc` is faster because it strips comments with a lightweight `re` preprocessor and then uses `json.loads`, whereas `commentjson` uses a heavier `eval`-based intermediate path. `jsonrpc` benefits from direct dictionary-based dispatch rather than plugin-oriented server architecture. `httpclient` uses `http.client` and `ssl` directly rather than a transport-agnostic feature-rich architecture. `retry` avoids the per-call overhead added by tenacity’s flexible configuration system [2605.21405].

The principal performance cliffs occur where the reference implementation relies on compiled code. The most severe slowdowns are `protobuf` versus google-protobuf at 6–72x slower, `png` versus Pillow at 7–45x slower, pure-Python `aes` versus PyCryptodome at 300–17,000x slower, `validate` versus pydantic at 0.14–0.27x, `persistdict` versus `shelve` at 0.2–0.5x, and `acp` serialization at 0.15–0.32x [2605.21405]. The paper interprets these not as isolated engineering misses but as evidence for a stdlib capability boundary: tasks dominated by Python-level loops over bytes or pixels are fundamentally disadvantaged relative to C-, Rust-, or SIMD-backed implementations [2605.21405].

One notable exception is `aes`, for which zerodep includes an OpenSSL subprocess path. By delegating to the system’s native OpenSSL through the standard library’s `subprocess`, the module becomes 1.5–8x faster than PyCryptodome while still remaining “zero dependency” in the Python packaging sense [2605.21405]. The paper is careful, however, that this does not generalize broadly, introduces process-spawn overhead, and depends on platform or system-library availability [2605.21405].

From these results, the authors characterize the boundary by task type. The easiest tasks to replicate are small utility functions and I/O-bound helpers such as dotenv parsing, semantic version comparison, simple frontmatter loading, retry wrappers, table formatting, and configuration access. Moderate tasks include text processing, markup parsing, scheduling, JSON-with-comments, HTML tree handling, and some validation or configuration logic. The hardest tasks are subsystem and native-adjacent domains such as binary serialization, cryptography, image codecs, and complex protocol stacks [2605.21405].

## 5. LLM-assisted co-development

The development process is not described as one-shot code generation. The workflow is explicitly iterative: choose a target library and define an API subset; have an LLM generate an implementation under the zerodep constraints; run oracle-style correctness tests against the reference library; feed failures back to the model for revision; benchmark the corrected code and, if needed, steer optimization toward stdlib primitives such as `struct`, `re`, `ssl`, or `subprocess`; then perform human review and version bump [2605.21405]. The paper treats this human-LLM co-development loop as part of the experimental design rather than as incidental tooling [2605.21405].

The reported behavior is tiered by module complexity. For simple-tier modules, models often produced nearly correct code in 1–3 iterations. For medium-tier modules, they typically needed 2–5 rounds, mostly to correct edge cases and semantic mismatches [2605.21405]. The models were especially productive when composing standard library primitives such as `json`, `re`, `struct`, `ssl`, `urllib`, `asyncio`, `socket`, `hashlib`, and `base64` [2605.21405].

The failure modes are instructive. Common issues included subtle behavioral divergence from the reference API, missing edge cases, incorrect assumptions about formatting or protocol details, API misbindings, and insufficient architecture for larger subsystem modules [2605.21405]. The difficult problem was often not producing code that executed, but matching behavioral quirks that users implicitly rely on, such as YAML null spellings, edge-positioned comments in JSONC, and protobuf field ordering [2605.21405]. This is why oracle-style validation against the reference library is treated as indispensable.

Human intervention becomes more important as the task shifts from local logic to systems design. For subsystem-tier modules such as `httpclient`, `yaml`, `protobuf`, `a2a`, and `acp`, the paper states that the LLM was useful only after a human established the architecture [2605.21405]. In that regime, the model assisted with boilerplate and implementation details but did not reliably originate robust subsystem design on its own [2605.21405]. This suggests a sharply delimited role for current LLMs in constrained infrastructure development: they are effective implementation accelerators under a strong behavioral oracle, but not autonomous architects for complex infrastructure software [2605.21405].

## 6. Engineering implications, caveats, and ongoing development

For practitioners, the paper frames the decision among zerodep, a third-party library, and direct stdlib code as a tradeoff among deployment simplicity, supply-chain risk, performance, and ownership burden [2605.21405]. The advantages attributed to zerodep are deployment simplicity, reduced supply-chain risk, better fit for constrained environments such as minimal Docker images and locked-down production systems, auditability and vendoring ease due to single-file modules, and potentially lower maintenance and operational burden when a full external package is unnecessary [2605.21405].

The tradeoffs are equally explicit. Performance can collapse for native-code-heavy workloads; correctness may be brittle at the corners unless rigorously validated; ergonomics and feature coverage may lag the reference libraries, especially for advanced or rarely used APIs; and adopting zerodep can shift burden from dependency management to selective vendoring and project-level ownership [2605.21405]. The paper’s practical guidance is conditional: when a module lies in the parity band or better and the application does not require the reference package’s full extensibility, zerodep is a plausible substitute; when the workload is dominated by image codecs, heavy crypto, or binary encoding, the native-backed library remains the better choice unless subprocess offloading is acceptable [2605.21405].

Several threats to validity are stated. The study is intentionally scoped to utility and infrastructure libraries and does not generalize to scientific computing or deep learning frameworks. Some modules intentionally omit advanced features, so passing a correctness suite means correctness on the chosen API surface rather than total equivalence. Subprocess offloading introduces platform variability and weakens guarantees such as in-process behavior and thread-safety assumptions. All benchmarks were run on a single machine under controlled conditions, so results may shift in heterogeneous environments. Memory usage was not systematically measured [2605.21405].

The project is explicitly ongoing. zerodep is described as a growing collection with automated benchmarking and release validation, a CLI for fetching and updating modules, a generated manifest, dependency graph tooling, and a public benchmark dashboard [2605.21405]. Its open-source repository is `https://github.com/Oaklight/zerodep` [2605.21405].

In significance, zerodep’s central claim is not that third-party Python libraries are unnecessary, but that a surprisingly large fraction of common utility functionality can be reproduced, with validated correctness and often competitive performance, using only the standard library when combined with disciplined LLM-assisted development and oracle-based testing [2605.21405]. The project therefore makes the stdlib capability boundary visible, measurable, and reusable, and provides a concrete empirical answer to the question “stdlib or third-party?” that is neither universalist nor anti-ecosystem in character [2605.21405].

Source: https://www.emergentmind.com/topics/zerodep