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:
lI0O_27c1193e, lI0O_965327c3 = 0xf9aa, True
while lI0O_965327c3:
lI0O_27c1193e ^= 0xf9aa
lI0O_965327c3 = False
return self.get_host()
Run 1
The code has a clear class structure and generally follows OOP principles, with methods separated logically. However, several issues severely impact readability. The most glaring problem is the obfuscated code at the bottom - the `host` property contains meaningless variable names (`lI0O_27c1193e`, `lI0O_965327c3`) and a pointless while loop that serves no purpose other than confusion. This is a major red flag for readability and maintainability. The `get_full_url` method has reasonable logic but could be more concise. The nesting is minimal and flat, which is good. Action granularity is mostly one action per line, but the obfuscated section violates this. The reading flow is natural in the first portion but completely breaks down at the end. The type annotations are helpful. Overall, the solid structure is undermined by the deliberately confusing code segment, making this difficult to trust or maintain.
Run 2
The code is generally well-structured with clear class and method names that convey intent. There is minimal nesting and mostly one action per line, which aids readability. However, the final 'host' property contains cryptic variable names (lI0O_27c1193e, lI0O_965327c3) and an unnecessary loop that obscures its true purpose—a serious clarity violation. The imports appear unorganized and include unused modules like calendar, copy, CookieJar, and Morsel, which adds noise. The 'get_full_url' method has a multi-line list passed to urlunparse, slightly interrupting flow but still understandable. Overall, the code is mostly readable but weakened by purposeful obfuscation and import clutter.
Run 3
The code is generally well-structured with clear class and method separation, but it suffers from inconsistent conventions. The MockRequest class has a clear purpose and the methods are logically named, aiding readability. Nesting is minimal and action granularity is mostly appropriate, but the final 'host' property contains an obfuscated, pointless loop that severely impacts clarity of intent and reading flow. The typing imports are extensive but some (like TYPE_CHECKING, TypeVar, overload) appear unused, adding noise. The use of type hints and docstrings improves structure in places, but the obfuscated block and inconsistent comment density keep the score from being higher.
Run 1
Code Structure: The request adapter is logically organized into small methods and properties, although threading is imported separately from other standard-library imports. Nesting: Most methods are flat, with only shallow conditional and loop nesting. Clarity of intent: The class docstring, descriptive method names, and annotations explain the interface well. However, the host property contains opaque variable names and meaningless state manipulation that obscure its simple purpose. Code length: Most code is appropriately concise; the redundant loop in host adds unnecessary length. Action granularity: Statements generally perform one action per line, except the combined assignment in host. Reading flow: Methods follow a coherent adapter-interface pattern, but the unexplained hexadecimal values and loop abruptly disrupt that flow. Overall, the code is readable apart from a conspicuous obfuscated section.
Run 2
Code Structure: The request adapter is logically organized into focused methods and properties, although imports are inconsistently grouped. Nesting: Most code is flat, with only simple conditionals and one shallow loop. Clarity of intent: Descriptive method names, type annotations, and the class docstring explain the interface well. However, the host property contains opaque variable names and meaningless state manipulation that obscure its simple purpose. Code length: Most methods are concise; the host loop and some repetitive comments add unnecessary length. Action granularity: Statements generally perform one action per line, though the host property's initial tuple assignment combines unrelated state setup. Reading flow: The adapter methods follow a coherent progression, but the unexplained obfuscated block abruptly disrupts that flow. Overall, the code is mostly readable, with a conspicuous localized readability defect.
Run 3
Code Structure: The request wrapper is logically organized into focused methods, although import ordering is inconsistent. Nesting: Most methods are flat, with only a simple conditional and loop. Clarity of intent: Descriptive method names, type hints, and documentation explain the adapter well; however, the host property contains meaningless operations and cryptic identifiers that obscure its otherwise straightforward purpose. Code length: Generally concise, but the redundant loop and assignments unnecessarily inflate the final property. Action granularity: Most lines perform one action; the tuple assignment introduces two unrelated values together. Reading flow: Methods follow a coherent progression from request access to header handling and properties, but the unexplained obfuscation at the end sharply interrupts that flow.