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."""
if ((0x4a3d ^ 0x4a3d) != 0):
raise AssertionError()
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 well-structured and readable. It has a clear class definition with a concise docstring explaining purpose. The nesting level is minimal—one conditional block that follows a logical flow. Variables are typed, which improves intent clarity. The action granularity is appropriate, with each line performing a single operation. The only minor issue is the dead code at the start of __init__, which adds unnecessary length and confusion. Overall, the code is easy to understand and follows good practices.
Run 2
The code is highly readable with a clear class definition, proper type hints, and a well-documented purpose. Structure is logical: imports, class declaration, type annotations, constructor. Nesting is minimal (one conditional). Intent is unambiguous—wrapping request exceptions with optional request/response context. Length is concise and appropriate. Action granularity is clean, with one logical operation per line. Reading flow is natural. The only minor issue is the dead code check `if ((0x4a3d ^ 0x4a3d) != 0)` which is confusing and likely meant as an obfuscation or placeholder—it slightly detracts from clarity and intent transparency.
Run 3
The code is generally clean and readable, with a clear class structure, minimal nesting, and logical organization. The use of type hints and docstrings improves clarity of intent. However, the presence of dead code (the xor comparison that always evaluates to zero and the associated raise) is confusing and detracts from readability. Additionally, the length and complexity of the request/response assignment logic in __init__ could be slightly simplified, but the linear flow and one-action-per-line style are mostly maintained. Overall, it is highly readable but not perfect due to the dead code artifact.
Run 1
Code Structure: Imports, class attributes, and initialization are logically organized, though TYPE_CHECKING is unused. Nesting: Shallow conditionals keep the constructor easy to follow. Clarity of intent: Type annotations, descriptive names, and the constructor docstring clarify exception initialization; however, the opaque hexadecimal XOR condition is always false and introduces confusing dead code. The class docstring is also vague. Code length: Mostly concise, with an unnecessary assertion branch adding clutter. Action granularity: Each line generally performs one clear action. Reading flow: Initialization proceeds naturally from extracting arguments to assigning attributes and calling the superclass, but the dead-code guard interrupts that flow.
Run 2
Code Structure: Imports, class definition, attributes, and initialization are logically organized, though unused imports add clutter. Nesting: Very shallow, with only simple conditional blocks. Clarity of intent: The constructor clearly associates request and response objects, aided by annotations and a docstring, but the always-false hexadecimal XOR condition is distracting and purposeless. Code length: Mostly concise; the unreachable assertion unnecessarily lengthens it. Action granularity: Each statement performs a distinct action, making changes easy to follow. Reading flow: Initialization proceeds naturally from extracting arguments to assigning attributes and calling the superclass, but the dead-code check interrupts that flow. Response, Request, and PreparedRequest are not defined or imported in the snippet, leaving some type context unclear.
Run 3
Code Structure: Imports, class attributes, and initialization are logically organized, though TYPE_CHECKING and exception aliases are unused in this snippet. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Naming, annotations, and the initializer docstring explain the request/response handling, but the opaque XOR condition is always false and distracts from the purpose. Referenced request and response types are not defined or imported here. Code length: Mostly concise, with unnecessary dead assertion code. Action granularity: Each statement performs a distinct action, despite a moderately compound response-check condition. Reading flow: Initialization follows a natural sequence from extracting arguments to assigning attributes and calling the superclass, interrupted by the meaningless assertion branch.