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 with clear separation of concerns. Each class method has a single responsibility, and docstrings effectively explain non-obvious behavior (especially the MRO-related decisions in __init__ and __reduce__). Nesting is minimal—flat method bodies with no conditional complexity. Action granularity is good, with one logical action per line. The class hierarchy and imports are clear, though the multiple inheritance pattern requires some Python-specific knowledge to fully understand. Variable naming is conventional and readable. The main minor drawback is that the docstrings, while thorough, could be slightly more concise. Overall, the code demonstrates high readability with thoughtful documentation of subtle design choices.
Run 3
The code is generally readable: it has clear imports, a docstring, and comments explaining non-obvious initialization ordering and pickling behavior. The class structure is logical, nesting is minimal, and each method has a clear purpose. The main readability issues are the use of multiple inheritance with non-obvious MRO implications, the slightly dense __init__ and __reduce__ logic, and the presence of verbose comments that assume the reader already knows the class hierarchy. Variable names are reasonable, and line length is acceptable. Overall, it is concise and well-organised, but the domain-specific error handling and MRO manipulation may require background knowledge.
Run 1
Code Structure: The class is logically organized into initialization and serialization methods, though InvalidJSONError is not defined or imported in the snippet, and two imports appear unused. Nesting: The code is flat, with no nested control flow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the specialized exception behavior and inheritance requirements clearly. Code length: The implementation is concise; the lengthy docstrings provide useful context but could be tightened. Action granularity: Each executable line performs a single clear action. Reading flow: Imports, class declaration, initialization, and pickling support follow a natural order. Minor grammatical issues in the documentation and missing dependency context slightly reduce readability.
Run 2
Code Structure: The class is logically organized, with initialization and pickling behavior separated into focused methods, though InvalidJSONError is not defined or imported in the snippet. Nesting: There is no unnecessary nesting. Clarity of intent: Type annotations and detailed docstrings explain the subtle multiple-inheritance behavior, but minor grammatical errors reduce polish. Code length: The implementation is concise; the docstrings are somewhat verbose but provide useful context. TYPE_CHECKING and BaseHTTPError are unused in the snippet and add clutter. Action granularity: Each executable line performs one clear action. Reading flow: Imports, class declaration, initialization, and serialization follow a natural sequence, although understanding the inheritance interactions requires familiarity with exception construction and pickling.
Run 3
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. Nesting: Flat method bodies with no nested control flow. Clarity of intent: Descriptive names, type annotations, and docstrings explain the non-obvious multiple-inheritance behavior well, though references to IOError require outside context. Code length: Implementation is concise, but the explanatory docstrings are somewhat lengthy and contain minor wording issues. Action granularity: Each statement performs one clear action. Reading flow: Imports, class declaration, initialization, and serialization follow a natural order; missing dependency context slightly interrupts comprehension.