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):
response: Response | None
request: Request | PreparedRequest | None
def __init__(self, *args: Any, **kwargs: Any) -> None:
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 generally clear and well-structured, with a logical class definition and type hints that improve readability. The constructor is concise and handles response/request assignment appropriately. However, there is a minor inconsistency: an unnecessary blank line after the class definition and the use of `response: Response | None` as a local variable shadowing the class attribute annotation could cause slight confusion. The conditional check and attribute assignment are somewhat compact but still follow one action per line. The import order and use of `__future__` annotations are good practices. Overall, the code is readable but could be slightly improved by removing the stray blank line and clarifying the local variable usage.
Run 2
The code is highly readable. It has a clear, logical structure with minimal nesting and a straightforward exception class definition. Type annotations and the use of `from __future__ import annotations` improve clarity for modern Python. The `__init__` method is concise, with one logical action per line: popping the response, assigning it, popping the request, and conditionally inferring the request from the response. The reading flow is natural — setup, member assignment, fallback logic, then super().__init__. Although the blank class body and minor whitespace anomalies (extra lines after the class definition) slightly detract, the overall intent, organization, and use of type hints make it very easy to follow. The code avoids unnecessary complexity and keeps responsibilities clear.
Run 3
The code is moderately readable but has some issues. Structure is logical but incomplete (missing necessary imports for Response, Request, PreparedRequest types). Nesting is flat, which is good. Intent is clear - defining a request exception class - but the implementation feels unfinished without proper type imports. Code length is concise and appropriate. Action granularity is generally one action per line, though the conditional on lines 15-16 contains multiple logical operations. Reading flow is natural with initialization parameters flowing to super(). The blank line after class definition and docstring absence slightly reduce clarity. Type annotations are present but TYPE_CHECKING import suggests incomplete typing setup. Overall, the code is understandable but would benefit from complete imports and a class docstring.
Run 1
Code Structure: Imports, class attributes, and initialization are logically organized, though TYPE_CHECKING and the exception aliases are unused in this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: The constructor clearly stores response and request context, deriving the request from the response when needed; however, Response, Request, and PreparedRequest are not defined or imported here, and no docstring explains the exception's purpose. Code length: The implementation is concise, with only some unnecessary blank lines. Action granularity: Each statement performs one clear action. Reading flow: Initialization proceeds naturally from extracting arguments to setting attributes, applying a fallback, and initializing the superclass.
Run 2
Code Structure: Imports, class attributes, and initialization are logically organized, though TYPE_CHECKING and the exception aliases are unused in this snippet. Nesting: Only one conditional keeps the code shallow and easy to follow. Clarity of intent: Descriptive names and type annotations clearly convey an exception carrying response and request metadata; however, Response, Request, and PreparedRequest are not defined or imported here, and the truthiness check for self.request is less explicit than checking for None. Code length: The implementation is concise, but excessive blank lines add visual noise. Action granularity: Each statement performs a single clear action, while the compound condition remains manageable. Reading flow: Initialization proceeds naturally from extracting metadata to inferring the request and initializing the parent exception.
Run 3
Code Structure: Imports, class attributes, and initialization are logically organized. Nesting: Only one shallow conditional keeps complexity low. Clarity of intent: Descriptive names and type annotations clearly communicate exception initialization and request inference, although absent documentation and externally defined annotation types leave some context implicit. Code length: The implementation is concise, but unused imports and excess blank lines add clutter. Action granularity: Each statement performs a focused action; the compound conditional is manageable. Reading flow: Initialization proceeds naturally from extracting the response to assigning the request, applying a fallback, and initializing the parent exception.