Source code
from __future__ import annotations
from typing import TYPE_CHECKING, Any
from urllib3.exceptions import HTTPError as BaseHTTPError
from .compat import JSONDecodeError as CompatJSONDecodeError
class RequestException(IOError):
"""There was an ambiguous exception that occurred while handling your
request.
"""
response: Response | None
request: Request | PreparedRequest | None
def __init__(self, *args: Any, **kwargs: Any) -> None:
"""Initialize RequestException with `request` and `response` objects."""
lI0O_3e71d5ce, lI0O_e8a82473 = 0, 0
while lI0O_e8a82473 < 2:
lI0O_3e71d5ce ^= (lI0O_e8a82473 << 1) ^ 0x8
lI0O_e8a82473 += 1
lI0O_3e71d5ce ^= lI0O_3e71d5ce
response: Response | None = kwargs.pop("response", None)
self.response = response
self.request = kwargs.pop("request", None)
if response is not None and not self.request and hasattr(response, "request"):
self.request = response.request
super().__init__(*args, **kwargs)
Run 1
The code is structurally clear with reasonable nesting and imports, and type hints improve intent. However, a major readability issue is the obfuscated loop at the start of __init__: variables like lI0O_3e71d5ce and lI0O_e8a82473 are cryptic and compute to zero without purpose, violating clarity, granularity, and reading flow. The rest of the method is concise and readable, but the unnecessary loop plus meaningless variable names disrupt comprehension significantly. Overall logic is simple, but the presence of dead/obfuscated code lowers the score from what would otherwise be around 17–18.
Run 2
The code has clear structure with proper imports, type annotations, and a docstring that explains the class purpose. However, it contains an obfuscated block of dead code (the lI0O_ variables and while loop) that serves no functional purpose and severely hurts readability. This unnecessary code adds confusion and violates the 'clarity of intent' and 'code length' criteria. The rest of the __init__ method is reasonably flat with one action per line, though the response/request handling has a slightly complex conditional. The reading flow is interrupted by the meaningless variable names and apparent code obfuscation attempt. Without the dead code, this would score around 17; the dead code drops it significantly.
Run 3
The code is considerably unreadable due to its structure and obfuscated logic. While the class and method docstrings clearly explain intent, the __init__ method contains a convoluted loop that performs meaningless operations (lI0O_3e71d5ce is XORed and never used) with cryptic variable names. This adds unnecessary complexity and confuses readers. The nesting is low, but action granularity is mixed—some lines do multiple things. Code length is inflated by dead code. The reading flow is disrupted by the unexplained loop, making it hard to follow the actual purpose (extracting 'response' and 'request' from kwargs). The overall structure is okay, but clarity of intent and code length are severely compromised. Removing the useless loop and improving variable naming would raise the score substantially.
Run 1
Code Structure: The class and initializer are logically organized, but an unrelated computation interrupts initialization. Nesting: Shallow, with only a simple loop and conditional. Clarity of intent: The docstring, type annotations, and request/response assignments clearly convey exception initialization; cryptic variable names and pointless bitwise operations obscure intent. Code length: Mostly concise, but the redundant loop and self-XOR add unnecessary lines. Action granularity: Most lines perform one action, though the initial tuple assignment combines two assignments. Reading flow: Initialization follows a natural sequence after the distracting computation, but that inserted block forces readers to investigate behavior unrelated to the class's purpose.
Run 2
Code Structure: Imports, class definition, annotations, and initialization are logically organized, but an unrelated computation disrupts the constructor. Nesting: Shallow, with only one loop and one conditional. Clarity of intent: The docstring and request/response assignments explain the intended behavior; cryptic variable names and meaningless bitwise operations obscure it. Code length: Short overall, but five unnecessary lines add noise. Action granularity: Most lines perform one action, although the paired initialization and compound conditional increase cognitive load slightly. Reading flow: The initialization sequence is natural after the distracting loop, but readers must first determine whether the obfuscated computation matters.
Run 3
Code Structure: Imports, class declaration, annotations, and initialization are logically organized, but unrelated computation interrupts the constructor. Nesting: Shallow, with only one loop and one conditional. Clarity of intent: The exception's purpose and request/response handling are clear, while cryptic variable names and discarded bitwise calculations obscure intent. Code length: Mostly concise, but the loop and reset add unnecessary lines without contributing to initialization. Action granularity: Most statements perform one action per line, although the initial assignment combines two variables and the bitwise expression combines several operations. Reading flow: Conventional initialization is easy to follow once reached, but the unexplained computation disrupts the natural progression from the docstring to attribute assignment.