psf / requests · Architecture

GitHub metadata records Python as the primary language, with topics including http, client and cookies. The analyzer treats docs, src and tests as subsystems. It processed 130 files: 42 in tests, 26 in docs, 20 in src, 19 in .github, 7 in ext, and 16 at the repository root.

• src holds the requests package with modules such as certs.py, help.py, api.py, sessions.py, models.py, adapters.py, cookies.py, auth.py, exceptions.py, compat.py, _types.py, _internal_utils.py, structures.py and __init__.py.
• tests holds 42 files, including test_requests.py, test_lowlevel.py, test_adapters.py and conftest.py.
• Root-level project files are README.md, pyproject.toml, setup.py and LICENSE.

The GitHub description calls the project a simple, elegant HTTP library.

The reconstruction overview counts three entrypoints, 310 resolved static call relations and 25 bounded execution paths. Two entrypoints are verified __main__ guards: running src/requests/certs.py or src/requests/help.py as a script starts there. The guards are one-liners — certs.py runs print(where()) and help.py runs main(). The third, tests/testserver/server.py, is a likely entrypoint by filename heuristic only.

Of the ten listed paths, two start at certs.py and end at once on an unresolved call to print or where. The other eight start at help.py and walk through main: two stop at json.dumps or print; two continue through info to platform.system or platform.release; four continue through info and _implementation to platform.python_implementation, platform.python_version or join. All ten end with terminal_reason unresolved_boundary; none shows a cycle or truncation, and help.py's __main__ → main → info → _implementation chain is the deepest local flow.

Every role below is inferred by the analyzer from static resolved call degree and entrypoint membership, not from observed execution.

• src/requests/utils.py is the most connected in the cited records: 52 incoming and 44 outgoing calls, labeled a service/core candidate.
• sessions.py (11 in, 57 out), models.py (5 in, 54 out) and adapters.py (3 in, 38 out) are service/core candidates dominated by outgoing calls.
• compat.py (52 in, 1 out) and exceptions.py (37 in, 2 out) absorb many calls and emit few.
• _types.py (13 in, 0 out) and _internal_utils.py (9 in, 0 out) look like leaves.
• In tests, testserver/server.py is an entry/orchestration candidate (52 in, 2 out) and test_lowlevel.py an orchestration candidate (0 in, 32 out).
• cookies.py, api.py, auth.py, structures.py, help.py and __init__.py fill out the cited set with moderate or small degrees.

Static relations split sharply: 2,579 of 3,080 are external or unresolved, 501 are local, and the edges are 2,566 calls plus 514 imports. Every one of the ten listed execution paths ends at an unresolved call instead of returning into analyzed code. The stopping points are names the analyzer could not resolve: print, where, json.dumps, platform.system, platform.release, platform.python_implementation, platform.python_version and join. No listed path reaches tests/testserver/server.py or any module outside certs.py and help.py, so the test server's boot and shutdown are not traced. In effect, the packet's execution picture covers the two script modules only.

The only parsed dependency record pins Sphinx 7.2.6 at line 3 of docs/requirements.txt, with scope recorded as runtime — documentation-side tooling for the docs subsystem. Manifest coverage is narrow: only requirements-style files are parsed, and pyproject.toml dependency tables are ignored.

Inside tests, testserver/server.py is recorded as an entry/orchestration candidate with 52 incoming calls (widely called from tests), while tests/utils.py is a leaf with 7 incoming calls. tests/test_lowlevel.py is recorded as an orchestration candidate with 0 incoming and 32 outgoing calls; tests/test_requests.py shows 1 incoming and 18 outgoing. Overall, 501 local relations were resolved against 2,579 unresolved ones, so the cross-part dependency picture is sparse.

The static analysis does not resolve reflection, runtime dependency injection, dynamic imports, monkey-patching, generated code, framework runtime wiring or dynamic dispatch. Install, run and build inference is partial, and no installation command has been verified. README-derived claims are line-based captures that may include code lines, so they stand only as author claims. The analyzer's capability fields describe the tooling, not this repository, and were excluded from evidence. How sessions.py, models.py and adapters.py cooperate at runtime — wiring, configuration, dispatch — is not established by this packet. 42 test-like files are recorded, but tests as behavior lie outside the static record.

The packet's teaching path recommends manifests and important files first, then tracing a bounded execution path, then the unresolved boundaries before changing code. A concrete order: pyproject.toml and setup.py, then src/requests/__init__.py, then compat.py and utils.py where calls concentrate, then sessions.py, models.py and adapters.py for the core, and finally the test fixtures. Close by walking help.py's local chain to its unresolved endpoints and reading tests/testserver/server.py as the shared test server.