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:
"""Wraps a `requests.PreparedRequest` to mimic a `urllib2.Request`.
The code in `http.cookiejar.CookieJar` expects this interface in order to correctly
manage cookie policies, i.e., determine whether a cookie can be set, given the
domains of the request and the cookie.
The original request object is read-only. The client is responsible for collecting
the new headers via `get_new_headers()` and interpreting them appropriately. You
probably want `get_cookie_header`, defined below.
"""
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:
# Only return the response's URL if the user hadn't set the Host
# header
if not self._r.headers.get("Host"):
return self._r.url
# If they did set it, retrieve it and reconstruct the expected domain
host = to_native_string(self._r.headers["Host"], encoding="utf-8")
parsed = urlparse(self._r.url)
# Reconstruct the URL as we expect it
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)) # type: ignore[return-value]
def add_header(self, key: str, val: str) -> None:
"""cookiejar has no legitimate use for this method; add it back if you find one."""
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 is highly readable with clear structure and organization. It wraps a requests.PreparedRequest to mimic urllib2.Request, and each method has a singular, well-defined purpose. Nesting is minimal: the only conditional is in get_full_url, and the logic is broken into understandable steps. Clarity of intent is strong with docstrings and comments explaining the 'why' behind non-obvious behavior. Code length is concise and avoids redundancy. Action granularity is good: generally one operation per line, though the return in get_header is dense but acceptable. Reading flow is natural: properties and methods are logically grouped, and type hints improve comprehension. Minor deductions: the 'type' class-level annotation before __init__ is slightly out of place, get_full_url's reconstruction could be split for even clarity, and the NotImplementedError method is verbose but justified. Overall, a well-structured, maintainable snippet.
Run 2
The code is highly readable. It has a clear class structure with a single responsibility, minimal nesting, and well-named methods that map directly to the interface they mimic. Docstrings and inline comments clarify non-obvious behavior, such as the Host header reconstruction. Each method is concise and generally performs one logical action. Type hints improve clarity. The only deductions are for a few long method calls and the NotImplementedError message, which is slightly conversational but still clear.
Run 3
The code is highly readable with clear structure, minimal nesting, and a well-defined purpose. It logically organizes a request wrapper class, though it could be more concise in places. Function boundaries are clean, and the implementation generally follows one action per line. The main weakness is that some methods are slightly verbose or redundant, but the overall flow and intent are easy to follow.
Run 1
Code Structure: The class is logically organized around adapting a request to a cookie-handling interface, although several imports are unused in this snippet and threading is separated from other standard-library imports. Nesting: Methods are flat, with only a simple conditional and an early return. Clarity of intent: The class docstring, descriptive method names, annotations, and comments make its purpose clear; the abbreviated _r attribute is less explicit. Code length: Most methods are concise, though interface-required wrappers and some repetitive comments add length. Action granularity: Statements generally perform one action per line; the nested lookup in get_header is slightly denser. Reading flow: Initialization, request accessors, header operations, and properties follow a natural sequence, with consistent formatting.
Run 2
Code Structure: The class is logically organized into initialization, request-interface methods, header handling, and properties, though imports are inconsistently ordered and several appear unused. Nesting: Control flow is shallow, with a simple conditional and early return. Clarity of intent: Descriptive method names, type annotations, and a detailed class docstring explain the adapter's purpose; the abbreviated attribute `_r` and unexplained `PreparedRequest` reference slightly reduce clarity. Code length: Methods are concise, although some comments repeat obvious operations and interface wrappers add verbosity. Action granularity: Statements generally perform one action per line, and the multiline URL reconstruction is easy to scan. Reading flow: Method grouping and consistent formatting support natural reading, with minor disruption from import organization and the long inline type-ignore comment.
Run 3
Code Structure: The class is logically organized into initialization, request-interface methods, header handling, and properties, though imports appear ungrouped and several are unused in this snippet. Nesting: Methods are flat, with a single conditional and early return in get_full_url. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the adapter's purpose; the abbreviated attribute _r and references to PreparedRequest without a visible import slightly reduce clarity. Code length: Methods are concise, although interface wrappers and some explanatory comments add verbosity. Action granularity: Statements generally perform one action per line; the nested dictionary lookup in get_header is slightly denser. Reading flow: Consistent formatting and short methods make the class easy to scan, with minor interruptions from import ordering and a long inline type-ignore comment.