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 well-structured and follows clear organizational patterns. It uses a single class with a clear purpose: wrapping a PreparedRequest to mimic urllib2.Request for cookiejar compatibility. Nesting is minimal — the only conditional in get_full_url is flat and straightforward. Intent is clearly communicated through the class docstring and method names, though type hints could be more consistent (e.g., PreparedRequest missing import). The code is concise without being terse, with each method focused on a single responsibility. Action granularity is mostly one action per line, though the return statement in get_header packs several operations. Reading flow is natural, with methods ordered logically from simple getters to more complex URL reconstruction. Minor issues include a type comment in get_header and the assertion pattern in __init__, which could be more explicit. Overall, the code demonstrates good readability with clear separation of concerns and minimal complexity.
Run 3
The code has some positive structural elements like clear class naming, type hints, and separation of methods, but suffers from several readability issues. The main problems are unnecessary imports (`calendar`, `copy`, `time`, `threading`, `MutableMapping`, etc.) that add noise. There are also missing dependencies - `PreparedRequest` is referenced but not imported, making the code incomplete. The nesting in `get_full_url()` is acceptable, but the overall intent is unclear without seeing the broader context. Action granularity is mostly good with one operation per line. However, the `get_header` method has a type ignore comment that suggests potential issues, and the `add_header` method raising NotImplementedError creates an inconsistent interface. The class seems to be a compatibility wrapper, but the complexity of URL reconstruction in `get_full_url()` could benefit from extraction. Import ordering is inconsistent. While methods are reasonably named and focused, the incomplete imports and dead imports significantly impact readability.
Run 1
Code Structure: The wrapper class is logically organized into initialization, request accessors, header operations, and compatibility properties, though imports are not consistently grouped and several appear unused. Nesting: Control flow is flat, with one simple conditional and an early return. Clarity of intent: The class docstring, descriptive method names, and type annotations clearly explain the adapter's purpose; the abbreviated field `_r` and undefined-in-snippet `PreparedRequest` slightly reduce clarity. Code length: Methods are concise, although compatibility forwarding methods and some repetitive comments add length. Action granularity: Statements generally perform one action per line, and URL reconstruction is formatted clearly. Reading flow: Methods follow a natural progression, with consistent spacing and formatting. Minor distractions include the trailing type-ignore comment and the misplaced threading import.
Run 2
Code Structure: The class is logically organized into request accessors, header operations, and compatibility properties, though several imports appear unused and threading is separated from other standard-library imports. Nesting: Control flow is shallow, with a simple conditional and early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring explain the adapter's purpose well; the abbreviated _r attribute and misleading reference to a response URL slightly reduce clarity. Code length: Methods are concise, although compatibility wrappers and the lengthy docstring add some reading overhead. Action granularity: Statements generally perform one action per line, and URL reconstruction is formatted clearly. Reading flow: The progression from initialization through request metadata to headers and properties is natural, with minor distractions from import clutter and a long get_header expression.
Run 3
Code Structure: A cohesive adapter class organizes request access and header handling into focused methods, though imports appear cluttered and include unused names. 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 interface and purpose well; the abbreviated attribute _r and externally defined PreparedRequest slightly reduce clarity. Code length: Most methods are concise, although compatibility wrappers and explanatory comments add 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 request metadata to headers and compatibility properties, with consistent formatting. Minor distractions include threading placed after local imports and a comment referring to a response URL despite wrapping a request.