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, *arg: Any, **kwa: 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, *arg)
InvalidJSONError.__init__(self, *self.args, **kwa)
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 generally readable with clear structure and intent. It defines a custom JSONDecodeError class that combines behavior from two parent classes. The class structure is logical and follows a clear pattern: __init__ and __reduce__ methods with docstrings explaining the 'why' behind the implementation. Nesting is minimal, and action granularity is mostly one step per line, though the __init__ method involves multiple conceptual actions. The docstrings are helpful for understanding the subtle MRO and pickling concerns. However, readability is slightly reduced by dense comments that require background knowledge about inheritance and pickling, and the __reduce__ return type annotation is unclear. The code is concise but could be improved with brief inline comments for key steps. Overall, it is maintainable for experienced Python developers but may be challenging for newcomers to understand the rationale behind the method overrides.
Run 2
The code is well-organized with clear class hierarchy and descriptive docstrings. However, the multiple inheritance pattern (InvalidJSONError, CompatJSONDecodeError) and the dual __init__ calls make it complex. The __init__ method has moderate complexity due to argument forwarding, though comments help clarify. Nesting is minimal and flat. Action granularity is mostly one action per line, improving readability. The __reduce__ method is concise with a clear purpose. The docstrings are verbose but informative, adding context needed for understanding the error handling edge cases. Overall, the code is readable but requires some Python inheritance and exception handling knowledge.
Run 3
The code has clear purpose and generally good structure with docstrings explaining non-obvious design decisions. However, readability is reduced by vague argument names (`*arg`, `**kwa`), three-level deep inheritance, and multiple class instantiations on separate lines that are conceptually one action. The `__reduce__` docstring is long and complex. There is no blank line separating imports from class definition, and the class hierarchy is not immediately evident. The code is concise but could benefit from more descriptive parameter names and simpler explanations of the hook methods. Overall it is understandable but requires careful reading to grasp the intent and interactions among base classes.
Run 1
1. Code Structure: Imports, class definition, and methods are logically organized, although InvalidJSONError is not defined or imported in the snippet and some imports are unused. 2. Nesting: Minimal nesting makes the code easy to scan. 3. Clarity of intent: Descriptive class and method names, type annotations, and docstrings explain the initialization and pickling behavior; abbreviated parameter names arg and kwa reduce clarity slightly. 4. Code length: The implementation is concise, though the docstrings are somewhat lengthy and contain minor grammatical issues. 5. Action granularity: Each executable line performs one clear action. 6. Reading flow: Initialization followed by serialization support creates a natural progression, with explicit parent-method calls making the multiple-inheritance behavior understandable.
Run 2
Code Structure: Imports and a focused exception class are logically organized, though InvalidJSONError is not defined or imported in the snippet, and two imports appear unused. Nesting: Minimal nesting makes both methods easy to scan. Clarity of intent: Docstrings clearly explain the unusual initialization and pickling behavior; abbreviated parameter names arg and kwa are less conventional and slightly obscure intent. Code length: The implementation is concise, although the explanatory docstrings are somewhat verbose. Action granularity: Each statement performs one clear action. Reading flow: Initialization followed by serialization behavior creates a natural progression, but understanding the multiple-inheritance interaction requires familiarity with exception internals.
Run 3
Code Structure: Imports and a single exception class with two focused methods provide logical organization, though InvalidJSONError is undefined in the snippet and some imports are unused. Nesting: Flat method bodies make the code easy to scan. Clarity of intent: Docstrings explain the subtle initialization and pickling behavior well, but abbreviated parameter names arg and kwa reduce clarity slightly. Code length: The implementation is concise; the explanatory docstrings are lengthy but useful given the multiple-inheritance behavior. Action granularity: Each executable line performs one clear action. Reading flow: Initialization followed by serialization support is natural, with explicit parent-method calls making execution order visible. Minor grammatical issues in the docstrings and missing surrounding context prevent a higher score.