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]:
remaining_steps = 3
while remaining_steps > 0:
remaining_steps -= 1
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 good documentation and fairly clear intent, but several issues hurt readability. The get_header method is overloaded and confusing: it retrieves headers from two separate dictionaries without a clear explanation. The get_new_headers method contains a pointless loop that decrements a counter without any effect. Import order is scattered, and there's unused or unclear importing (threading, TYPE_CHECKING, MutableMapping, coding). The MockRequest mock is readable but the comment style is very verbose in some places and too brief in others. Type hints are present and help. The overall structure is passable but not excellent; the class is well-contained but the methods feel uneven, with some very clear and others obscure. The dead code and odd import length undermine readability, leaving the reader to wonder if they are missing something important.
Run 2
The code is generally well-structured and readable, with clear class and method definitions. Naming is descriptive and intent is mostly clear. However, there is a suspicious `get_new_headers` method containing a meaningless `while` loop that does nothing, which hurts clarity and suggests dead or debug code. Some methods are trivial wrappers that could be simplified, but they improve compatibility. The reading flow is natural, and nesting is shallow. Import organization is slightly cluttered but acceptable. Overall, it's readable but not exemplary due to the confusing loop and minor verbosity.
Run 3
The code is well-structured with clear class and method separation, consistent docstrings, and type hints that enhance clarity. Most methods follow a flat, readable flow with minimal nesting, and each action is generally on its own line. The exception is the leftover 'while remaining_steps > 0' loop in get_new_headers, which is dead code and briefly disrupts readability. Naming is descriptive, and the class purpose is explicitly documented. Overall, it is highly readable with only minor issues.
Run 1
Code Structure: The class is logically organized into request-interface methods and properties, though imports are poorly grouped and several appear unused. Nesting: Methods remain flat, with only a simple conditional and loop. Clarity of intent: Descriptive method names, type annotations, and the class docstring explain the adapter well; however, the pointless countdown in get_new_headers obscures intent, and PreparedRequest has no visible import. Code length: Most methods are concise, but the countdown and some repetitive comments add unnecessary length. Action granularity: Statements generally perform one action per line; the nested dictionary lookups in get_header are slightly dense. Reading flow: Methods follow a coherent progression, and formatting is consistent, but the misplaced threading import and unexplained countdown interrupt otherwise natural reading.
Run 2
Code Structure: The class is logically organized into initialization, request-interface methods, header handling, and properties, though import ordering is inconsistent and several imports are unused. Nesting: Control flow is shallow, with simple conditionals and one loop. Clarity of intent: Descriptive method names, type annotations, and a detailed class docstring explain the adapter's purpose; however, the pointless countdown in get_new_headers obscures an otherwise straightforward accessor. Code length: Most methods are concise, but the countdown adds unnecessary lines and the imports add clutter. Action granularity: Statements generally perform one action per line; the nested dictionary lookup in get_header is slightly denser but still understandable. Reading flow: Methods and property wrappers follow a natural progression, with whitespace and comments aiding scanning. The unexplained loop and minor inconsistencies interrupt an otherwise readable implementation.
Run 3
Code Structure: The class logically groups request-adapter methods and properties, though imports are inconsistently organized and several appear unused. Nesting: Control flow is shallow, with an early return keeping URL handling flat. Clarity of intent: Descriptive method names, type annotations, and the class docstring explain the adapter well; however, the unexplained countdown in get_new_headers obscures an otherwise simple getter, and the comment referring to a response URL is misleading. Code length: Most methods are concise, but the countdown adds unnecessary lines and some comments restate the code. Action granularity: Statements generally perform one action per line. Reading flow: Methods progress naturally from request information to header handling and property wrappers, although the late threading import and redundant loop interrupt the flow.