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."""
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 highly readable with clear structure and purpose. It defines a custom exception class with explicit type annotations and a focused initializer that handles request/response attribution cleanly. Nesting is minimal—only one conditional—and the logic flows naturally from parameter extraction to fallback assignment to superclass initialization. Each meaningful action occupies its own line, and the docstring clarifies intent. Variable names are descriptive, and type hints enhance clarity. The only minor deductions are for the slightly dense conditional that combines multiple checks and assignments, which could be marginally clearer if split, and the unused imported exceptions, which add minor noise. Overall, the code is concise, well-organized, and easy to follow.
Run 2
The code is highly readable. Structure is logical, with imports at top and a single class definition. Nesting is minimal: one conditional inside __init__ with a guard clause. Intent is crystal clear — it defines a custom exception class for HTTP requests, attaching request and response objects. Length is concise and appropriate. Action granularity is good, with one meaningful operation per line. Reading flow is natural, from imports to class definition to method logic. The docstring and type hints further improve clarity. Minor deduction for the slightly condensed conditional line and the use of `BaseHTTPError` import which appears unused, but these are negligible in context. Overall, this code is nearly exemplary in readability by Python standards.
Run 3
The code is well-structured with clear class definition and proper type annotations. It uses a single class with one method, maintaining flat nesting and logical organization. The intent is clear: handling ambiguous request exceptions with request/response context. The constructor is concise, extracting keywords and setting attributes before calling super(). Action granularity is good with one logical operation per line. Reading flow is natural, moving from docstring to attribute declarations to initialization logic. Minor deductions: the conditional line is slightly dense, and the response/request relationship logic could benefit from a brief comment explaining why it falls back to response.request. Type annotations add clarity but also length. Overall, this is highly readable code that follows Python best practices.
Run 1
Code Structure: Imports, class documentation, type annotations, and initialization are logically organized, though several imports are unused in this snippet. Nesting: Only one conditional keeps the code nearly flat and easy to scan. Clarity of intent: Descriptive names, annotations, and the initializer docstring clearly explain how request and response are stored; the class docstring is somewhat vague, and referenced types are not defined or imported here. Code length: Concise, with no substantial redundancy. Action granularity: Each statement performs a distinct action, although the conditional combines three checks. Reading flow: Initialization proceeds naturally from extracting the response to assigning attributes, inferring the request, and initializing the superclass. Additional spacing between imports and the class would improve presentation.
Run 2
Code Structure: Imports, exception class, annotations, and initializer are logically organized, though several imports appear unused in this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: Descriptive names, type annotations, and the initializer docstring clearly explain request/response handling; the class docstring is vague, and referenced types are not defined here. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one action per line, although extracting and removing keyword arguments combines operations idiomatically. Reading flow: Initialization proceeds naturally from extracting the response to assigning attributes, inferring the request, and initializing the superclass. The compound condition adds minor reading effort.
Run 3
Code Structure: Imports, class documentation, attributes, and initialization are logically organized. Nesting: Only one shallow conditional keeps complexity low. Clarity of intent: Descriptive names and type annotations clearly convey exception initialization, although the class docstring is vague and several referenced types are not defined or imported in the snippet. Code length: Concise overall, but unused imports add minor clutter. Action granularity: Each statement performs a distinct action, with no compressed multi-statement lines. Reading flow: Initialization proceeds naturally from extracting response data to setting request data, applying a fallback, and initializing the superclass. The compound conditional requires slightly more attention but remains readable.