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, n: PreparedRequest) -> None:
assert _is_prepared(n)
self._r = n
self._new_headers: dict[str, str] = {}
self.type = urlparse(self._r.url).scheme
def a(self) -> str:
return self.type
def b(self) -> str:
return urlparse(self._r.url).netloc
def c(self) -> str:
return self.b()
def d(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
o = to_native_string(self._r.headers["Host"], encoding="utf-8")
p = urlparse(self._r.url)
# Reconstruct the URL as we expect it
return urlunparse(
[
p.scheme,
o,
p.path,
p.params,
p.query,
p.fragment,
]
)
def e(self) -> bool:
return True
def f(self, q: str) -> bool:
return q in self._r.headers or q in self._new_headers
def g(self, r: str, s: str | None = None) -> str | None:
return self._r.headers.get(r, self._new_headers.get(r, s)) # type: ignore[return-value]
def h(self, t: str, u: 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 i(self, v: str, w: str) -> None:
self._new_headers[v] = w
def j(self) -> dict[str, str]:
return self._new_headers
@property
def k(self) -> bool:
return self.e()
@property
def l(self) -> str:
return self.c()
@property
def m(self) -> str:
return self.b()
Run 1
This code is extremely difficult to read and understand. The most critical flaw is the complete lack of semantic naming: methods and attributes are named with single letters (a, b, c, d, e, f, g, h, i, j, k, l, m), making the intent completely opaque. The class name 'MockRequest' provides some context, but the method names reveal nothing about their purpose, requiring readers to constantly reference external documentation or guess. The code structure is moderately logical, with related methods grouped together, and action granularity is generally acceptable with one action per line. However, the dense blocks of comments within the 'd' method suggest the code is doing something non-obvious. The reading flow is severely disrupted by the cryptic names, forcing readers to jump back and forth mentally. Overall, while the code may be functionally correct, its readability is severely compromised, making it nearly impossible to maintain without extensive external documentation.
Run 2
This code is heavily obfuscated through single-letter method names (a, b, c, d, e, f, g, h, i, j) and properties (k, l, m) that completely obscure the intent. While the structure is logically organized and nesting is minimal, the deliberate obfuscation destroys clarity of intent — methods like 'd()' require reading comments to understand they handle URL reconstruction. The code is concise but at the cost of being unreadable; reading flow is severely disrupted as readers must constantly map meaningless names to their actual functions. Action granularity is fine (one action per line), but the type hints and imports suggest an originally well-structured codebase that has been deliberately scrambled. The docstrings explain what each method does, which somewhat mitigates confusion, but this is not a substitute for meaningful naming. Overall, the code appears intentionally obfuscated, making it virtually unreadable without extensive documentation or reverse-engineering.
Run 3
The code uses single-letter method and variable names (a through m, n, o, p, q, etc.) which severely obscures intent, even though the docstring explains the class purpose. The structure is logical and relatively flat, and each action is generally on its own line, which aids readability. However, the unclear names make it difficult to understand what each method does without external knowledge of the interface being mimicked. The code length is reasonable and not overly long, but the obfuscated naming negates many structural strengths. The reading flow is disrupted by the need to constantly decode abbreviations. Overall, the code is functional but not self-documenting, and would require significant renaming to be considered highly readable.
Run 1
Code Structure: A logically organized wrapper class with small methods, although imports are inconsistently grouped. Nesting: Mostly flat, with one simple conditional and an early return. Clarity of intent: The class docstring, annotations, and comments explain the overall purpose, but single-letter method and parameter names obscure individual operations and their relationship to the expected request interface. Code length: Generally concise; some trivial forwarding methods and properties add navigation overhead. Action granularity: Statements typically perform one action per line, and URL reconstruction is clearly formatted. Reading flow: Method boundaries and straightforward control flow help, but understanding calls such as c() delegating to b() or k calling e() requires repeatedly tracing ambiguous names.
Run 2
Code Structure: A cohesive wrapper class separates responsibilities into small methods, although import ordering is inconsistent. Nesting: Very shallow; the single conditional uses an early return. Clarity of intent: The class docstring, comments, and type annotations explain the overall purpose, but single-letter method, property, parameter, and local-variable names obscure individual operations and interface relationships. PreparedRequest is also referenced without a visible import. Code length: Generally concise, though trivial forwarding methods and properties add reading overhead. Action granularity: Statements mostly perform one action per line, and the multiline URL reconstruction is easy to scan. Reading flow: Initialization followed by accessors and header operations provides reasonable organization, but deciphering opaque names requires repeatedly tracing calls. Overall, clean formatting and simple control flow are substantially undermined by poor naming.
Run 3
Code Structure: Logically organized into a single wrapper class with small methods, though imports are poorly grouped and several appear unused. Nesting: Very shallow; the only conditional uses an early return. Clarity of intent: The class docstring, comments, and type annotations explain the overall purpose, but single-letter method, property, parameter, and local names severely obscure individual operations and relationships. Code length: Generally concise, although trivial forwarding methods and properties add indirection. Action granularity: Statements mostly perform one action per line, and URL reconstruction is clearly formatted. Reading flow: Method layout is consistent and easy to scan, but understanding behavior requires repeatedly tracing opaque names; documentation references descriptive interface methods that are absent under those names, further disrupting comprehension.