dr-wire
A bounded, lifecycle-managed synchronous HTTP client core. dr-wire owns one
canonical client lifecycle: explicit bounds on connections and request bodies,
explicit timeouts on every phase, deterministic drain-on-close, and a closed
taxonomy of wire failures returned as values rather than leaked transport
exceptions. It is a foundational capability, isolated so that changing how
HTTP works is a visible boundary crossing; consumers depend on it
rev-pinned and update in lockstep.
The package depends on the standard library and httpx only. Nothing it
exposes is ever persisted: every value is an in-process description of one
wire exchange or one resource bound, and a consumer that records wire
outcomes maps these values into its own vocabulary at its own boundary.
Surface
HttpClientConfig
Every resource bound one client enforces, with no defaults, so an unsized client cannot be constructed:
from dr_wire import HttpClientConfig
config = HttpClientConfig(
timeout_seconds=120.0,
connect_timeout_seconds=30.0,
idle_timeout_seconds=90.0,
max_connections=10,
max_keepalive_connections=5,
max_request_bytes=1024 * 1024,
max_response_bytes=8 * 1024 * 1024,
)
Timeouts must be positive and finite, pool sizes and byte limits positive
integers, max_keepalive_connections at most max_connections, and neither
phase timeout above the general timeout. A phase timeout above the general
timeout is rejected rather than clamped, because clamping would enforce a
bound different from the one the caller chose.
BoundedHttpClient
from dr_wire import BoundedHttpClient, WireRequest, WireResponse
with BoundedHttpClient(config) as client:
with client.admit():
result = client.call(
WireRequest(
method="POST",
url="https://api.example.test/v1/chat",
headers={"content-type": "application/json"},
body=b'{"model": "m"}',
)
)
if isinstance(result, WireResponse):
...
call(request)is total for wire-level problems: it returns aWireResponseor aWireFailureand never raises for a timeout, a connection failure, a protocol violation, a refused byte bound, or an unrecognizedhttpxerror. Calling once the work drain has begun raisesRuntimeError, since reaching a closed client is a caller-lifecycle error rather than a wire condition; anything else it raises is a defect of this package. Every HTTP status, redirects included, comes back as aWireResponse; redirects are never followed and status meaning belongs to the caller.admit()holds one unit of caller work open against the drain.calltakes no admission of its own, so a caller whose operation spans several wire calls wraps the whole operation andclose()drains operations rather than individual calls.offload(fn)submits work to a client-owned executor created on first use and sized frommax_connections, so worker count and pool size cannot disagree. Offloaded work must not callclose()oroffload()on the client running it.close()is two-phase: it stops offload admission, drains offloaded work, stops work admission, drains admitted work, shuts down the executor, and closes the underlying client exactly once, leaving the client terminal. An exception escaping either drain wait aborts the close: the client still becomes terminal and releases its resources, without claiming the drain completed.
Wire values
WireRequest, WireResponse, WireFailure, and WireFailureKind describe
one exchange. WireFailureKind is a closed taxonomy — INVALID_URL,
CONNECT_ERROR, NETWORK_ERROR, REMOTE_PROTOCOL_ERROR,
LOCAL_PROTOCOL_ERROR, TIMEOUT, STALLED_RESPONSE, POOL_TIMEOUT,
REQUEST_TOO_LARGE, RESPONSE_TOO_LARGE, UNKNOWN — whose members are
never persisted.
Parsing helpers
parse_retry_after(value)returns aParsedRetryAfterfor a delta-seconds integer or a timezone-aware HTTP-date rendered canonically in UTC, andNoneotherwise. It applies no magnitude or length cap; bounding how far a hint may reach is the consumer's evidence policy.is_dispatchable_url(url)reports whether a URL carries an http or https scheme and a non-empty host. It is total and never raises.
Definitions
.defs/terms.toml and .defs/contracts.toml hold this repository's shared
vocabulary and binding rules, rendered at
the terms and contracts page.
Checks
bash scripts/pre-check.sh
License
MIT
Metadata
Release files for dr-wire 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| dr_wire-0.1.0.tar.gz | 13.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| dr_wire-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 30.0 kB
Release files / dr_wire-0.1.0.tar.gz
| Download URL | dr_wire-0.1.0.tar.gz |
|---|---|
| Size | 13.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
bca315e64c7f54a02cb2b2f6fd3fca0ce1d9ff1ab5ef90d807a5f71ac359b2a4
|
|
BLAKE2b-256 checksum How to use checksums |
941788031541fd25828c4fb6727f30a8caaf7a5145f9bdd4423760b86d153685
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 12, 2026.
Transparency logRelease files / dr_wire-0.1.0-py3-none-any.whl
| Download URL | dr_wire-0.1.0-py3-none-any.whl |
|---|---|
| Size | 16.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
94e9d04d44aef241900941cee2a340981e175abd18010a5cb3c14b6383ec94a1
|
|
BLAKE2b-256 checksum How to use checksums |
303da5ffbda2b174b12f00b4991b441235f959266ea4589f10ce7cd18c234c76
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 12, 2026.
Transparency log