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 has a clear purpose and is logically organized into a single class. However, readability is harmed by several issues. The class has inconsistent spacing between methods, with some methods packed together without blank lines, disrupting the reading flow. Some lines are unnecessarily long, and the `urlunparse` call is oddly formatted, with `parsed.scheme` and `host` cramped together on the same line while other arguments are on separate lines. The type hints are incomplete and inconsistent, and the `type` attribute is defined at the class level without clear necessity. Nesting is shallow, which is good, and most methods are concise. But the importer order and code structure could be improved, and the overall formatting feels uneven. The intent of the code is clear, and the method actions are mostly granular, but the visual inconsistency reduces readability.
Run 2
The code is moderately readable but inconsistent. Structure is logical for a wrapper class, but it suffers from irregular blank lines and cramped method grouping. Nesting is low, which is good. However, the `get_full_url` method contains an oddly formatted list with extraneous spaces that hurts readability. Action granularity is mostly one action per line, but some method definitions and docstrings are packed closely, making it harder to scan. Reading flow is mixed: comments are helpful, but missing blank lines after properties and some methods interrupt flow. The long `get_header` line and type ignore comment add clutter. Clarity of intent is decent due to docstrings and naming, but overall visual inconsistency reduces the score.
Run 3
The code is generally readable but has several structural and formatting issues. It follows a class-based design with clear methods, but the placement of `type: str` before `__init__` and inconsistent blank lines between methods disrupt flow. Some methods are missing blank lines, making the class feel cramped. Nesting is minimal, mostly flat, which is good. Clarity of intent is moderate: docstring helps, but methods like `get_full_url` contain inline comments and oddly spaced list formatting that reduce readability. Code length is appropriate, but action granularity in `urlunparse` is poor—multiple items are placed on one line in a scattered way. Reading flow suffers from inconsistent spacing and formatting. Overall, the logic is understandable, but formatting and organization could be improved for higher readability.
Run 1
Code Structure: A cohesive adapter class groups related request and header operations, though imports are poorly ordered and several appear unused in this excerpt. Nesting: Methods are flat, with only one simple conditional and an early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the interface; the abbreviated _r attribute and misleading reference to a response's URL slightly reduce clarity. Code length: Implementation is concise, although some comments repeat obvious operations. Action granularity: Most lines perform a single action, but the irregularly formatted URL component list puts multiple items on one line. Reading flow: Methods follow a sensible progression from URL access to header handling and properties, but inconsistent blank lines between methods, misplaced threading import, and awkward list spacing interrupt scanning.
Run 2
Code Structure: The class logically groups request-adapter responsibilities, but imports are poorly organized and several appear unused in this snippet. Nesting: Methods are mostly flat, with a simple conditional and early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the adapter's purpose; abbreviated attributes and the unexplained PreparedRequest reference slightly reduce clarity. Code length: Most methods are concise, though some comments restate operations and property wrappers add repetition required by the interface. Action granularity: Statements generally perform one action per line, but two URL components share an awkwardly spaced line. Reading flow: Methods follow a reasonable sequence, but inconsistent blank lines, irregular list formatting, and a long inline type-ignore comment disrupt visual scanning.
Run 3
Code Structure: The class logically groups request-adapter methods, although imports are poorly ordered and include several unused names. Nesting: Methods are shallow, with a straightforward conditional and early return. Clarity of intent: Descriptive method names, type annotations, and the class docstring clearly explain the adapter's purpose; the abbreviated attribute `_r` and a comment referring to a response rather than a request slightly weaken clarity. Code length: Most methods are concise, though some comments repeat obvious operations. Action granularity: Statements generally perform one action per line, but the malformed-looking URL argument formatting places multiple elements on one line. Reading flow: Method ordering is coherent, but inconsistent blank lines between methods and irregular whitespace in `urlunparse` interrupt scanning. Overall, the code is easy to understand despite noticeable formatting issues.