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 with a clear, logical class structure. Each method has a single, focused responsibility (e.g., get_host, add_header), and the class docstring effectively explains the purpose and context. Nesting is minimal, with only one conditional block in get_full_url. The use of type hints and properties enhances clarity without adding verbosity. Comments are informative and justify non-obvious design decisions, such as the NotImplementedError. The code length is appropriate for the described functionality. The reading flow is natural, with related methods grouped and a sensible ordering of public API followed by properties.
Run 3
The code is well-structured and readable. It uses a class with a clear single responsibility: adapting a PreparedRequest to the urllib2/cookiejar interface. Methods are short, focused, and mostly flat, with minimal nesting. Naming is descriptive and comments clarify non-obvious logic (e.g., URL reconstruction). The use of properties improves readability. Minor drawbacks include some private attribute access (`_r`, `_new_headers`) and a few longer methods like `get_full_url`, but the flow remains logical. Overall, it is easy to follow and understand the intent.
Run 1
Code Structure: A cohesive adapter class groups related request and header operations logically, although several imports are unused in this snippet and import ordering is inconsistent. Nesting: Methods are flat, with only a simple conditional and early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the compatibility interface; the abbreviated attribute _r and an unresolved PreparedRequest reference slightly reduce clarity. Code length: Mostly concise methods, though some comments repeat obvious operations and the interface includes repetitive accessors. Action granularity: Statements generally perform one action per line; the nested dictionary lookup in get_header is slightly denser. Reading flow: Initialization, request accessors, header operations, and properties follow a natural progression, with consistent formatting and useful whitespace.
Run 2
Code Structure: The class logically groups request-adapter behavior into focused methods, though unused imports and inconsistent import ordering add clutter. Nesting: Control flow is shallow, with a single conditional and an early return. Clarity of intent: Descriptive method names, type annotations, and a detailed class docstring clearly explain the adapter's purpose; the abbreviated attribute `_r` and apparently undefined `PreparedRequest` annotation introduce minor ambiguity. Code length: Most methods are concise, although interface-required wrappers and properties introduce some repetition. Action granularity: Statements generally perform one action per line; the nested dictionary lookups in `get_header` are slightly denser. Reading flow: Methods progress naturally from initialization through URL handling and header operations to compatibility properties. Comments help explain Host-header handling, but the reference to a response URL is misleading in this request wrapper.
Run 3
Code Structure: A cohesive wrapper class groups related request-adapter methods logically, though unused imports and the misplaced threading import add clutter. Nesting: Control flow is shallow, with a single conditional and early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring explain the compatibility role well; the abbreviated _r attribute and externally defined PreparedRequest slightly reduce clarity. Code length: Methods are concise, although repetitive compatibility accessors and some redundant comments add length. Action granularity: Statements generally perform one action per line, with readable multiline URL reconstruction. Reading flow: Initialization, request accessors, header handling, and properties follow a natural sequence. Minor import organization issues and an inaccurate reference to the response's URL interrupt an otherwise clear presentation.