Source code
from __future__ import annotations
import calendar
import copy
import time
from collections.abc import Iterator, MutableMapping
from http.cookiejar import Cookie, CookieJar, CookiePolicy
from typing import TYPE_CHECKING, Any, TypeVar, overload
from ._internal_utils import to_native_string
from ._types import is_prepared as _is_prepared
from .compat import Morsel, cookielib, urlparse, urlunparse
import threading
class MockRequest:
type: str
def __init__(self, request: PreparedRequest) -> None:
assert _is_prepared(request)
self._r = request
self._new_headers: dict[str, str] = {}
self.type = urlparse(self._r.url).scheme
def get_type(self) -> str:
return self.type
def get_host(self) -> str:
return urlparse(self._r.url).netloc
def get_origin_req_host(self) -> str:
return self.get_host()
def get_full_url(self) -> str:
if not self._r.headers.get("Host"):
return self._r.url
host = to_native_string(self._r.headers["Host"], encoding="utf-8")
parsed = urlparse(self._r.url)
return urlunparse(
[
parsed.scheme,
host,
parsed.path,
parsed.params,
parsed.query,
parsed.fragment,
]
)
def is_unverifiable(self) -> bool:
return True
def has_header(self, name: str) -> bool:
return name in self._r.headers or name in self._new_headers
def get_header(self, name: str, default: str | None = None) -> str | None:
return self._r.headers.get(name, self._new_headers.get(name, default))
def add_header(self, key: str, val: str) -> None:
raise NotImplementedError(
"Cookie headers should be added with add_unredirected_header()"
)
def add_unredirected_header(self, name: str, value: str) -> None:
self._new_headers[name] = value
def get_new_headers(self) -> dict[str, str]:
return self._new_headers
@property
def unverifiable(self) -> bool:
return self.is_unverifiable()
@property
def origin_req_host(self) -> str:
return self.get_origin_req_host()
@property
def host(self) -> str:
return self.get_host()
Run 1
The code has a clear class structure with cohesive methods for request handling, but readability is hindered by several issues. There's inconsistent formatting with blank lines (e.g., line 16), trailing whitespace after `get_header`, and no whitespace after the colon in the `type` annotation. Long lines in `get_header` and type hints reduce readability. Some methods have unnecessary multi-line formatting with blank comment-only lines (e.g., in `get_full_url`), while others are one-liners, creating inconsistent granularity. The naming is generally clear, but methods like `is_unverifiable` and `get_origin_req_host` are unclear without context. The `get_full_url` method has complex parsing logic that could benefit from helper functions or comments explaining the fallback strategy. Additionally, the abstract `add_header` raising `NotImplementedError` is a code smell that might confuse readers. Overall organization is logical, but implementation details and formatting inconsistencies suggest moderate readability.
Run 2
The code is well-structured and readable, using clear class and method names. It follows the single responsibility principle, with each method performing one focused task. Nesting is minimal, and the logic flows naturally. Type hints improve clarity of intent. Some minor issues affect readability: a few unused imports (calendar, time, threading, Iterator, MutableMapping, TYPE_CHECKING, Any, TypeVar, overload, CookieJar, CookiePolicy, Morsel, cookielib) add noise. The get_full_url method has multiple steps but remains understandable. The add_header method correctly raises NotImplementedError. Overall, the code is maintainable and easy to follow.
Run 3
The code is well-structured and follows clean patterns. The class has a clear single responsibility (mocking a request for cookie processing), with methods that are small and focused. Nesting is minimal throughout, and each method performs one action, making the code easy to follow. Type hints improve clarity, and the use of properties provides natural access patterns. The reading flow is logical, with methods organized by functionality. Minor deductions: the get_header method could be simplified, and the __init__ method has an assertion that could be replaced with a more explicit validation pattern. Overall, this code is highly readable and maintainable.
Run 1
Code Structure: Methods are logically grouped within a focused request adapter, though import ordering is inconsistent and several imports appear unused. Nesting: Very shallow, with a simple conditional and early return. Clarity of intent: Descriptive method names and type annotations communicate purpose, but the terse _r attribute, undefined PreparedRequest reference in the snippet, and lack of explanation for Host-header handling reduce clarity. Code length: Mostly concise; excessive blank lines and minor wrapper repetition add noise. Action granularity: Each statement generally performs one action, making execution easy to follow. Reading flow: Initialization, accessors, header operations, and properties follow a natural progression, although irregular whitespace and trailing spaces interrupt visual consistency.
Run 2
Code Structure: The class is logically organized into initialization, request accessors, header operations, and properties, though imports are inconsistently grouped and several appear unused. Nesting: Methods are flat, with only one simple conditional. Clarity of intent: Descriptive method names and type annotations make the adapter behavior understandable, but abbreviated attributes, the unexplained Host override, and the undefined PreparedRequest type in this snippet reduce clarity. Code length: Most methods are concise; thin accessor wrappers add some repetition but fit the interface. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: The progression is natural, but excessive blank lines, whitespace-only lines, and trailing spaces interrupt the otherwise clean presentation.
Run 3
Code Structure: The class logically groups request-adapter methods and properties, although imports are poorly ordered and several appear unused in this snippet. Nesting: Control flow is shallow, with a simple early return and no deeply nested blocks. Clarity of intent: Descriptive method names and type annotations make most behavior clear, but the abbreviated field _r and absence of a class docstring leave the adapter's purpose and interface requirements implicit. Code length: Methods are concise; some wrappers seem repetitive but plausibly support the expected interface. Action granularity: Statements generally perform one action per line, and the URL reconstruction is clearly formatted. Reading flow: Methods progress naturally from request metadata to header handling and properties, but excessive whitespace, trailing spaces, and the late threading import interrupt an otherwise clean presentation.