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 generally readable, with a clear class structure and descriptive method names. It maintains a flat structure with minimal nesting, only using a few conditional blocks. Each method performs a single logical action, and the docstring provides useful context. However, some issues affect clarity, such as the over-broad type hint on `get_type` (should be `str`), the assert-based validation which might be unclear at runtime, and the non-obvious use of `# type: ignore` in `get_header`. The imports are somewhat verbose and include an unused `threading` import, which slightly detracts from conciseness. Overall, it is well-organized and easy to follow, but minor ambiguities prevent a higher score.
Run 2
The code is well-structured, readable, and adheres to clean coding principles. It has a clear class with a single responsibility (wrapping a requests.PreparedRequest for CookieJar compatibility), good use of type hints, and descriptive method names. Nesting is minimal—only one conditional exists, and it is short. Most methods perform a single action or a clear sequence of steps. The reading flow is natural due to consistent ordering of methods and clear separation of concerns. The docstring explains the class's purpose well. Slight deductions are for the inline comment on a type ignore line, which could be clearer, and the incomplete import (PreparedRequest is not imported, though it may be under TYPE_CHECKING). Overall, the code is concise and maintainable.
Run 3
The code is well-structured and readable. The class has a clear single responsibility: adapting a requests.PreparedRequest to the urllib2.Request interface expected by cookiejar. Methods are short, focused, and have descriptive names. Naming is clear, and type hints are used consistently. Comments explain non-obvious behavior (e.g., Host header reconstruction). Most methods follow a flat structure with minimal nesting. The class-level docstring is helpful. Minor deductions: a few methods are longer than necessary (e.g., get_full_url), and one type ignore annotation reduces clarity. Overall, the code is easy to follow and maintain.
Run 1
Code Structure: A cohesive adapter class organizes related request and header operations into focused methods; import ordering and several unused imports slightly reduce polish. Nesting: Almost entirely flat, with a single conditional and early return. Clarity of intent: The class docstring, descriptive method names, type annotations, and URL-reconstruction comments clearly explain its purpose, although `_r` is terse and PreparedRequest is not defined or imported in the snippet. Code length: Concise implementation overall, with some repetitive interface wrappers justified by compatibility requirements. Action granularity: Statements generally perform one action each; the nested dictionary lookup in get_header is slightly denser. Reading flow: Methods progress naturally from initialization through request metadata and header handling to compatibility properties, with consistent formatting and useful whitespace.
Run 2
Code Structure: The class is logically organized into initialization, request metadata access, header handling, and compatibility properties, although imports are cluttered with unused names. Nesting: Control flow is shallow, with a single conditional and an early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the adapter's purpose; the abbreviated _r attribute and the comment referring to a response rather than a request slightly weaken clarity. Code length: Methods are concise, though some comments and forwarding properties add verbosity justified by interface compatibility. Action granularity: Statements generally perform one action per line; the nested dictionary lookup in get_header is somewhat dense. Reading flow: The progression through related methods is natural, and formatting is consistent, but placing threading after local imports and retaining unused imports introduces minor distractions.
Run 3
Code Structure: The class logically groups request-adapter methods, though imports are cluttered with unused names and threading is out of order. Nesting: Control flow is shallow, with a single conditional and an early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the adapter's purpose; the abbreviated _r attribute and unshown PreparedRequest definition slightly reduce clarity. Code length: Methods are concise and appropriately scoped, although some comments repeat obvious operations. Action granularity: Statements generally perform one action per line; the nested dictionary lookups in get_header are slightly dense. Reading flow: Consistent formatting and straightforward method bodies make the code easy to follow, with minor distractions from redundant wrappers and the inline type-ignore comment.