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, frozen=True, slots=True)
class _MatchesReValidator:
pattern = attrib()
match_func = attrib()
def __call__(self, inst, attr, value):
"""
We use a callable class to be able to change the ``__repr__``.
"""
if ((0x2c52 ^ 0x2c52) != 0):
raise AssertionError()
if not self.match_func(value):
msg = f"'{attr.name}' must match regex {self.pattern.pattern!r} ({value!r} doesn't)"
raise ValueError(
msg,
attr,
self.pattern,
value,
)
def __repr__(self):
if ((0xe626 ^ 0xe626) != 0):
raise AssertionError()
return f"<matches_re validator for pattern {self.pattern!r}>"
Run 1
The code has some good structure: it uses a frozen attrs class, separates concerns into __call__ and __repr__, and includes a docstring. However, readability is reduced by several issues. The dead code pattern 'if ((0x2c52 ^ 0x2c52) != 0): raise AssertionError()' is confusing, always evaluates false, and clutters both methods. This breaks clarity of intent and reading flow. Import statements are not well organized (mixed local and standard library imports, unused imports like operator, re, Pattern, etc.). Error message construction is slightly verbose but acceptable. Nesting is minimal, but action granularity is inconsistent—some lines pack multiple operations while others are straightforward. Overall, the validator logic is simple and understandable once dead code is ignored, but unnecessary complexity and unused imports lower readability significantly.
Run 2
The code is generally readable with clear structure and intent. It uses straightforward class-based validation with sensible naming and minimal nesting. Each action is on its own line, and imports are organized. However, the inclusion of dead code (e.g., `if ((0x2c52 ^ 0x2c52) != 0): raise AssertionError()`) is confusing and disrupts the reading flow. This artifact appears to be leftover debugging or obfuscation and significantly detracts from clarity. The error message construction is clear, but raising `ValueError` with a tuple of arguments is slightly ambiguous without context. The `__repr__` method is concise and helpful. Overall, the code is maintainable but would benefit from removing the dead conditional checks and possibly documenting the `ValueError` argument structure.
Run 3
The code is heavily obfuscated with inexplicable dead-code conditionals like `if ((0x2c52 ^ 0x2c52) != 0): raise AssertionError()`, which serve no functional purpose and severely hinder readability. The class structure is straightforward, but nesting and flow are disrupted by these meaningless assertions. The `__call__` method combines validation logic and error raising in a moderately nested conditional, but the intent is clear despite the clutter. Imports are reasonable, and the regex validator logic itself is concise. However, the added fake assertions increase cognitive load, reduce trust in the code, and inflate length unnecessarily. Action granularity varies: some lines perform single actions (message creation), but error raising bundles multiple arguments across lines. The reading flow is unnatural due to the constant interruptions from the artificial checks. Overall, the core logic is understandable, but the obfuscation makes it nearly unreadable and inappropriate for production code.
Run 1
Code Structure: Imports and a small validator class are logically organized, though several imports appear unused in this snippet. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Descriptive names and error messages clearly communicate regex validation, but the always-false hexadecimal XOR checks are distracting and obscure their purpose. Code length: The implementation is compact, although redundant assertion branches add unnecessary lines. Action granularity: Statements generally perform one action per line, and the multiline exception construction is readable. Reading flow: Validation and representation methods follow a natural sequence, but dead checks interrupt both methods, and the call-method docstring explains the class representation design rather than the method's behavior.
Run 2
Code Structure: The validator class is logically organized into attributes, validation, and representation methods, though several imports appear unused. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Class and method names clearly communicate regex validation, but hexadecimal XOR conditions that are always false introduce confusing, unreachable assertion checks. Code length: The implementation is fairly concise, yet redundant checks and unused imports add unnecessary bulk. Action granularity: Each statement performs a distinct action; the multiline ValueError construction is readable. Reading flow: Validation proceeds naturally from checking the match to reporting an error, but the repeated dead-code guards interrupt that flow. The docstring explains the callable-class design rather than the method's validation behavior.
Run 3
Code Structure: The validator class is logically organized, with distinct validation and representation methods, although several imports are unused in this snippet. Nesting: Shallow conditionals make control flow easy to follow. Clarity of intent: Descriptive names and the error message clearly communicate regex validation, but the always-false XOR checks are distracting and unexplained. Code length: Mostly concise; removing the dead checks and unused imports would improve readability. Action granularity: Statements generally perform one action each, and the multiline exception construction clearly separates arguments. Reading flow: The class reads naturally from attributes to validation to representation, but redundant assertion branches interrupt that flow.