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.
"""
if ((0x4f1 ^ 0x4f1) != 0):
raise AssertionError()
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.
"""
if ((0x2a78 ^ 0x2a78) != 0):
raise AssertionError()
return CompatJSONDecodeError.__reduce__(self)
Run 1
The code has clear docstrings and logical inheritance structure, but is heavily obscured by dead code assertions (e.g., `if ((0x4f1 ^ 0x4f1) != 0): raise AssertionError()`) that add confusion and noise. The class hierarchy is clear, but the purpose of some operations is not immediately obvious. Nesting is flat, which is good, but the unrelated assertions harm clarity of intent and reading flow. Action granularity is acceptable, with one operation per line, but the class is not concise due to these redundant checks. The code length is slightly inflated, and the overall readability suffers from the presence of meaningless conditional statements. The docstrings explain the 'why' well, but the actual code contains ambiguous and misleading elements, preventing a higher score.
Run 2
The code is structured logically with clear class definitions and docstrings explaining non-obvious behavior, which aids clarity of intent. Nesting is flat and action granularity is reasonable. However, readability is harmed by the dead-code assertions (e.g., `if ((0x4f1 ^ 0x4f1) != 0): raise AssertionError()`), which add confusion and unnecessary length. The class name `JSONDecodeError` collides conceptually with the imported `CompatJSONDecodeError`, but the docstrings mitigate ambiguity. Reading flow is generally natural, though the redundant assertions interrupt it. Overall, the code is understandable but could be improved by removing the no-op checks and simplifying the multiple inheritance explanation.
Run 3
The code is clear and logically organized. It defines a custom exception class combining two parent exceptions with well-written docstrings explaining the non-obvious initialization and pickling behavior. Nesting is minimal, mostly flat. Clarity of intent is strong. Code length is appropriate, though the redundant `if ((0x4f1 ^ 0x4f1) != 0): raise AssertionError()` checks add noise and could be removed. Action granularity is mostly one action per line. Reading flow is natural due to good docstring placement. The only notable issue is the unnecessary assertions, which slightly reduce readability.
Run 1
Code Structure: The class is logically organized into initialization and pickling methods, though InvalidJSONError is not defined or imported in the snippet, and some imports are unused. Nesting: Minimal nesting makes the methods easy to scan. Clarity of intent: Descriptive names and docstrings explain the multiple-inheritance behavior, but the opaque XOR conditions, which are always false, introduce distracting dead code. Code length: The implementation is short, although the dead checks and lengthy docstrings add unnecessary bulk. Action granularity: Each statement performs a single action, supporting readability. Reading flow: Imports, class declaration, and methods follow a natural sequence, but the pointless assertion branches interrupt otherwise straightforward logic.
Run 2
Code Structure: The class is logically organized into initialization and serialization methods, though InvalidJSONError is not defined or imported in the snippet and some imports are unused. Nesting: Both methods are mostly flat, with only shallow conditional blocks. Clarity of intent: Descriptive names and docstrings explain the inheritance and pickling behavior, but opaque XOR conditions that always evaluate to false introduce distracting dead code. Code length: The implementation is short, although verbose docstrings and redundant assertion blocks add unnecessary length. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: Initialization followed by serialization is natural, but the meaningless checks interrupt the flow and make readers question their purpose.
Run 3
Code Structure: The exception class is logically organized into initialization and pickling methods, but InvalidJSONError is undefined in the snippet and several imports are unused. Nesting: Mostly flat, with only shallow conditionals. Clarity of intent: Descriptive names and docstrings explain the multiple-inheritance behavior, but hexadecimal XOR checks that are always false introduce confusing, purposeless code. Code length: The implementation is short, although the dead checks and somewhat verbose docstrings add unnecessary length. Action granularity: Each statement performs a single action, making individual operations easy to follow. Reading flow: Initialization and serialization follow a natural sequence, but the dead assertion branches interrupt that flow, and minor grammatical issues in the documentation reduce polish.