zerodep: Evaluating Python’s Stdlib-Only Ecosystem

• zerodep is a collection of stdlib-only modules reimplementing popular Python libraries to reduce dependency bloat and mitigate supply-chain risks.
• It enforces strict constraints—single-file design, no external imports, drop-in API compatibility, and correctness validation against reference libraries.
• Empirical benchmarks show that two-thirds of modules achieve performance parity, while CPU-intensive tasks reveal the stdlib capability boundary.

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

2. Corpus, categories, and complexity structure

The paper reports 44 modules across 12 categories and three complexity tiers (Ding et al., 20 May 2026). The categories are network, protocol, serialization, validation, text, config, terminal, crypto, image, process, storage, and devtools (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026). API compatibility is therefore assessed behaviorally rather than nominally: the same calls are issued to both implementations and outputs are compared for equality (Ding et al., 20 May 2026).

The paper notes that some modules intentionally omit rare or deprecated features, and that these omissions are documented explicitly in the module docstrings (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026). The reference libraries are pinned in a conda environment, and all 44 modules passed their correctness suites (Ding et al., 20 May 2026).

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

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$ (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). The paper is careful, however, that this does not generalize broadly, introduces process-spawn overhead, and depends on platform or system-library availability (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). The paper treats this human-LLM co-development loop as part of the experimental design rather than as incidental tooling (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). The models were especially productive when composing standard library primitives such as json, re, struct, ssl, urllib, asyncio, socket, hashlib, and base64 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026). In that regime, the model assisted with boilerplate and implementation details but did not reliably originate robust subsystem design on its own (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). Its open-source repository is https://github.com/Oaklight/zerodep (Ding et al., 20 May 2026).

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 (Ding et al., 20 May 2026). 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 (Ding et al., 20 May 2026).