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 JSONDecodeError(InvalidJSONError, CompatJSONDecodeError):
"""Couldn't decode the text into json"""
def __init__(self, *args: Any, **kwargs: Any) -> None:
"""
Construct the JSONDecodeError instance first with all
args. Then use it's args to construct the IOError so that
the json specific args aren't used as IOError specific args
and the error message from JSONDecodeError is preserved.
"""
CompatJSONDecodeError.__init__(self, *args)
InvalidJSONError.__init__(self, *self.args, **kwargs)
def __reduce__(self) -> tuple[Any, ...] | str:
"""
The __reduce__ method called when pickling the object must
be the one from the JSONDecodeError (be it json/simplejson)
as it expects all the arguments for instantiation, not just
one like the IOError, and the MRO would by default call the
__reduce__ method from the IOError due to the inheritance order.
"""
return CompatJSONDecodeError.__reduce__(self)
Run 1
The code is well-structured with clear class definition, logical MRO handling, and explicit intent through docstrings. It maintains flat nesting, concise methods, and one action per line. Minor readability trade-offs include slightly complex inheritance (necessary for the use case) and somewhat dense docstrings, but overall it is highly readable and maintainable.
Run 2
The code is well-structured and readable. It has a clear class hierarchy with explicit docstrings explaining non-obvious design decisions, particularly around MRO and pickling. Nesting is minimal, actions are separated logically, and naming is descriptive. The only minor issues are that the base classes (InvalidJSONError, BaseHTTPError, TYPE_CHECKING) are not shown, requiring some context, and the type annotation `tuple[Any, ...] | str` is slightly unusual but still clear. Overall, intent is well-documented and flow is natural.
Run 3
The code is well-structured and readable. It uses clear class inheritance, a docstring that explains the purpose, and concise method implementations. The __init__ method has a clean flow with comments explaining the non-obvious inheritance ordering and why it matters. The __reduce__ method is similarly clear, with a helpful docstring explaining the pickling behavior. Nesting is minimal, and actions are generally one per line. The only minor issues are that the code requires some familiarity with Python's multiple inheritance and error class hierarchies to fully grasp the rationale, making it slightly less accessible to junior developers. Overall, the code demonstrates good clarity of intent and logical organization.
Run 1
Code Structure: Imports and a focused exception class are logically organized, although InvalidJSONError is not defined or imported in the snippet and two imports appear unused. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the subtle initialization and pickling behavior; missing context for InvalidJSONError slightly reduces clarity. Code length: Implementation is concise, though the explanatory docstrings are somewhat verbose and contain minor grammatical issues. Action granularity: Each statement performs one clear action. Reading flow: Initialization followed by serialization support creates a natural progression, with consistent indentation and spacing within the class; additional separation between imports and the class would improve presentation.
Run 2
Code Structure: The class cleanly separates initialization from pickling behavior, although InvalidJSONError is undefined in the supplied snippet and two imports are unused. Nesting: There is no nested control flow, making the implementation easy to scan. Clarity of intent: Descriptive names, type annotations, and docstrings explain the otherwise subtle multiple-inheritance behavior. Minor grammatical issues slightly reduce polish. Code length: The implementation is concise, though the explanatory docstrings are somewhat verbose. Action granularity: Each statement performs one distinct action. Reading flow: Imports, class declaration, constructor, and serialization method follow a natural order; understanding the explicit parent-method calls requires some familiarity with exception inheritance and Python's method resolution order.
Run 3
1. Code Structure: A focused exception class with logically separated initialization and pickling methods; however, InvalidJSONError is not defined or imported in the snippet, and two imports are unused. 2. Nesting: Flat method bodies with no nested control flow make scanning easy. 3. Clarity of intent: Descriptive names, type annotations, and docstrings explain the unusual multiple-inheritance behavior well, though understanding it requires familiarity with MRO and exception serialization. 4. Code length: Implementation is concise, but the docstrings are somewhat verbose and contain minor grammatical issues. 5. Action granularity: Each statement performs one clear action. 6. Reading flow: Imports, class declaration, initialization, and serialization follow a natural order; the missing base-class context slightly interrupts comprehension.