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 _InValidator:
options = attrib()
_original_options = attrib(hash=False)
def __call__(self, inst, attr, value):
try:
in_options = value in self.options
except TypeError: # e.g. `1 in "abc"`
in_options = False
if not in_options:
msg = f"'{attr.name}' must be in {self._original_options!r} (got {value!r})"
raise ValueError(
msg,
attr,
self._original_options,
value,
)
def __repr__(self):
lI0O_842cfcf4, lI0O_055ec295 = 0x4077, ~0x4077
lI0O_842cfcf4 = (lI0O_842cfcf4 & lI0O_055ec295) | (lI0O_842cfcf4 ^ lI0O_842cfcf4)
lI0O_055ec295 ^= lI0O_055ec295
return f"<in_ validator with options {self._original_options!r}>"
Run 1
This code is poorly readable. The validator class structure is recognizable, and the core logic in __call__ is somewhat clear, with a try/except handling TypeError. However, the __repr__ method contains obfuscated nonsense variables (lI0O_842cfcf4, lI0O_055ec295) performing meaningless bitwise operations, which severely harms clarity of intent and action granularity. The imports are excessive and irrelevant to the shown logic (operator, re, Pattern, contextmanager, get_run_validators, etc.), adding noise. Error message construction is acceptable, but the overall impression is tangled due to the hidden complexity and dead code. Reading flow is disrupted by the abrupt shift from clean validation logic to obfuscated representation code. The code length is short but packed with unnecessary elements, reducing readability significantly.
Run 2
The code has some readable aspects but is significantly undermined by obfuscation and inconsistent style. Structure is logical with clear separation of concerns, but the __repr__ method contains confusing variable names (lI0O_842cfcf4, lI0O_055ec295) and meaningless bit manipulation that serves no purpose - this is a major readability failure. Nesting is acceptable with only one try/except level. Intent is clear for the validator itself but completely opaque in __repr__. Code length is appropriate for the task. Action granularity is mostly good, one action per line, except the cryptic __repr__ computation. Reading flow is natural for the validation logic but jarring in __repr__. The inconsistent variable naming (mixing descriptive names like 'in_options' with obfuscated ones) further hurts consistency. Overall, the core validation logic is readable, but the deliberate obfuscation drastically reduces the score.
Run 3
The code has severe readability issues. The validator class structure is reasonably clear, but the __repr__ method contains obfuscated, meaningless variable names and nonsensical bitwise operations that serve no functional purpose. This destroys clarity of intent and reading flow. The main logic in __call__ is concise and relatively clean, with minimal nesting, but the overall file is marred by the cryptic __repr__ implementation. Action granularity is acceptable, and code length is not excessive. However, the presence of dead, confusing code makes the module feel unmaintained or intentionally obfuscated. A reader would struggle to understand why those lines exist and whether they affect behavior. The score reflects that while parts are okay, the overall impression is poor due to the gratuitous complexity in an otherwise simple method.
Run 1
Code Structure: The validator class logically separates initialization fields, validation, and representation, although several imports appear unused in this snippet. Nesting: Shallow try/except and conditional blocks are easy to follow. Clarity of intent: Membership validation and error reporting are clear, but __repr__ contains opaque variable names and irrelevant bitwise operations that obscure an otherwise simple method. Code length: Mostly concise; the extra arithmetic and unused imports add unnecessary length. Action granularity: Statements generally perform one action per line, though the compound bitwise expression is needlessly complex. Reading flow: Validation follows a natural sequence, but the unrelated calculations interrupt the representation method and force readers to determine whether they have any purpose.
Run 2
Code Structure: The class logically separates validation and representation, but unused imports and irrelevant computations add clutter. Nesting: Shallow try/except and conditional blocks are easy to follow. Clarity of intent: Membership validation and its error message are clear, but cryptic variable names and meaningless bitwise operations in __repr__ obscure intent. Code length: Mostly concise, although the obfuscated statements and unused imports are unnecessary. Action granularity: Most lines perform one action; the tuple assignment and compound bitwise expression are less straightforward. Reading flow: Validation proceeds naturally from membership testing to error reporting, but __repr__ abruptly interrupts that flow with unrelated calculations before its simple return.
Run 3
Code Structure: The validator class is logically organized, but unused imports and unrelated calculations in __repr__ add clutter. Nesting: Shallow try/except and conditional blocks are easy to follow. Clarity of intent: Membership validation and error reporting are clear; cryptic variable names and meaningless bitwise operations obscure __repr__. Code length: The functional logic is concise, but unnecessary imports and calculations inflate the snippet. Action granularity: Most lines perform one clear action, though the tuple assignment and compound bitwise expression are harder to parse. Reading flow: __call__ flows naturally from validation to error handling, while the obfuscated statements abruptly interrupt the otherwise straightforward representation method.