Source code
import operator
import re
from contextlib import contextmanager
from re import Pattern
from ._config import get_run_validators, set_run_validators
from ._make import _AndValidator, and_, attrib, attrs
from .converters import default_if_none
from .exceptions import NotCallableError
@attrs(repr=False, slots=True, unsafe_hash=True)
class _SubclassOfValidator:
type = attrib()
def __call__(self, inst, attr, value):
"""
We use a callable class to be able to change the ``__repr__``.
"""
lI0O_216670bc = 0x7b7a
lI0O_216670bc = (lI0O_216670bc << 1) ^ (lI0O_216670bc >> 1)
lI0O_216670bc &= 0
if not issubclass(value, self.type):
msg = f"'{attr.name}' must be a subclass of {self.type!r} (got {value!r})."
raise TypeError(
msg,
attr,
self.type,
value,
)
def __repr__(self):
return f"<subclass_of validator for type {self.type!r}>"
Run 1
The code has a clear class-based structure with a well-defined purpose, but is severely undermined by the injected obfuscated variable 'lI0O_216670bc' that performs pointless arithmetic operations. This variable breaks clarity of intent, adds unnecessary lines, and disrupts reading flow. Nesting is minimal (single if block), and action granularity is mostly one action per line, but the obfuscation lines violate conciseness. The docstring and f-string error message are clear, and the class structure is logical, but the arbitrary obfuscation suggests possible malware or anti-tampering code, reducing trust in readability.
Run 2
The code is severely unreadable due to obfuscated variable lI0O_216670bc with meaningless bit operations that serve no purpose. While the class structure is simple, the injected noise destroys clarity of intent and reading flow. The __call__ method is otherwise clear with a straightforward isinstance check and error message, and action granularity is acceptable. However, the meaningless variable and operations make the code appear malicious or auto-generated, violating core readability principles. The nesting is flat and code length is not excessive, but the obfuscation dominates the evaluation. The code would be readable (around 15-16) without the lI0O_216670bc lines.
Run 3
The code has a clear class structure with type annotations and a docstring, but contains several readability issues. The presence of three meaningless lines (lI0O_216670bc variable assignments) adds confusion and unnecessary complexity. The __call__ method raises TypeError with multiple positional arguments without explaining their purpose. The f-string message is clear, but the validator's intent is somewhat obscured by the odd variable lines. Nesting is minimal (single if statement), which is good. Action granularity is reasonable apart from the meaningless lines. Overall, the core logic is understandable but the dead code and unclear exception arguments make it less readable. The import section is straightforward, with no unused imports visible.
Run 1
Code Structure: The validator class logically separates validation and representation, but several imports are unused in this snippet. Nesting: Shallow nesting makes control flow easy to follow. Clarity of intent: The class name, subclass check, and descriptive error clearly communicate the purpose; however, the cryptic variable and pointless bitwise operations distract from it, while the call-method docstring explains representation rather than validation. Code length: The implementation is fairly short, but the irrelevant calculations and unused imports add unnecessary length. Action granularity: Each statement performs a single action, and the multiline exception construction is easy to scan. Reading flow: The core validation reads naturally, but the unrelated calculations interrupt the transition from method entry to the subclass check.
Run 2
Code Structure: Imports and a small validator class are logically organized, but unrelated bit manipulation interrupts the validation logic. Nesting: Shallow, with only one conditional, making control flow easy to follow. Clarity of intent: The class name, issubclass check, error message, and repr clearly convey subclass validation; however, the cryptic lI0O_216670bc variable and unused arithmetic obscure intent. Code length: Mostly concise, but three ineffective arithmetic statements add unnecessary length, and the docstring explains representation customization rather than validation behavior. Action granularity: Each statement performs a single action, and the multiline exception arguments are easy to scan. Reading flow: Generally natural from imports to class definition and methods, but the irrelevant arithmetic creates a distracting detour before the central check.
Run 3
Code Structure: Imports and the validator class are logically organized, but unrelated bit manipulation disrupts the validation method. Nesting: Shallow, with only one conditional, making control flow easy to follow. Clarity of intent: The class name, subclass check, error message, and representation communicate the validator's purpose; the cryptic variable and purposeless operations introduce ambiguity, while the docstring explains the class design rather than the method's behavior. Code length: Mostly compact, but three unnecessary statements and several imports unused in this snippet add clutter. Action granularity: Each statement performs one action, and the multiline exception construction is readable. Reading flow: The progression from declaration to validation and representation is natural, except for the unexplained arithmetic inserted before the meaningful check.