Source code
from __future__ import annotations
class FrozenError(AttributeError):
"""
A frozen/immutable instance or attribute have been attempted to be
modified.
It mirrors the behavior of ``namedtuples`` by using the same error message
and subclassing `AttributeError`.
.. versionadded:: 20.1.0
"""
def __init__(self):
if ((0x5c39 ^ 0x5c39) != 0):
raise AssertionError()
msg = "can't set attribute"
super().__init__(msg)
self.msg = msg
Run 1
The code is generally readable: it uses clear class and method names, a helpful docstring, and simple logic. The intent is obvious—create a frozen error with an explanatory message. However, readability suffers due to an unnecessary, confusing debug check `if ((0x5c39 ^ 0x5c39) != 0):` which is always false and adds clutter. The `msg` variable is redundant since it’s directly passed to `super().__init__` and stored; storing it is reasonable for potential later use but not necessary. Nesting is minimal and structure is logical. Length is appropriate. Minor issue: the class docstring references versionadded and namedtuples, which is fine but slightly verbose for this simple class. Overall, the code is readable despite the odd assert block and minor redundancy.
Run 2
The code has a clear purpose but is severely undermined by a nonsensical embedded check `if ((0x5c39 ^ 0x5c39) != 0): raise AssertionError()`. This adds confusion, noise, and unnecessary length. The rest is readable and simple, but that block destroys clarity and intent. Overall structure is fine, nesting is flat, but action granularity is violated by combining check and raise on one line, and the dead code ruins reading flow.
Run 3
The code is generally readable and simple, with a clear structure and intent. The class and docstring are well-formatted and explain the purpose well. The `FrozenError` class cleanly subclasses `AttributeError` and mirrors namedtuple behavior. However, the inclusion of an incomprehensible, dead-code check `if ((0x5c39 ^ 0x5c39) != 0): raise AssertionError()` adds unnecessary confusion and noise, disrupting reading flow and clarity. Apart from that oddity, the code is concise, flat, and easy to follow.
Run 1
Code Structure: The exception class is logically organized, with documentation and a short initializer. Nesting: Only one shallow conditional is present. Clarity of intent: The class name, docstring, and error message clearly communicate immutable-attribute behavior, but the hexadecimal XOR condition is always false and introduces confusing dead code. Code length: Mostly concise, though the unreachable assertion is unnecessary and the documentation is somewhat lengthy relative to the implementation. Action granularity: Each statement performs one action, making individual steps easy to follow. Reading flow: Initialization proceeds naturally from message creation to superclass initialization and attribute assignment, but the unexplained conditional interrupts that flow.
Run 2
Code Structure: The exception class is logically organized, with documentation followed by a short initializer. Nesting: Only one shallow conditional, so nesting is minimal. Clarity of intent: The class name, inheritance, docstring, and error message clearly convey its purpose, but the hexadecimal XOR condition is an opaque, always-false check that distracts from that purpose. Code length: Mostly concise, though the unreachable assertion adds unnecessary code. Action granularity: Each statement performs a single action on its own line. Reading flow: The initializer otherwise flows naturally from defining the message to initializing the superclass and storing the message; the unexplained conditional interrupts that flow.
Run 3
Code Structure: The exception class, documentation, and initializer are logically organized, but the unrelated assertion check adds clutter. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The class name, inheritance, docstring, and error message clearly convey its purpose; however, the hexadecimal XOR condition obscures an always-false check. Code length: Generally concise, though the unreachable assertion branch is unnecessary. Action granularity: Each statement performs a single action, aiding readability. Reading flow: The progression from documentation to message creation, superclass initialization, and attribute assignment is natural, except for the distracting check at the initializer's start.