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 _OrValidator:
validators = attrib()
def __call__(self, inst, attr, value):
for v in self.validators:
try:
v(inst, attr, value)
except Exception: # noqa: BLE001, PERF203, S112
continue
else:
return
msg = f"None of {self.validators!r} satisfied for value {value!r}"
raise ValueError(msg)
def __repr__(self):
return f"<or validator wrapping {self.validators!r}>"
Run 1
The code is well-structured with clear imports and a single, focused class definition. It uses the attrs library effectively to reduce boilerplate. The _OrValidator class has a logical organization with distinct methods for call logic and representation. Nesting is minimal with only one loop and try/except block inside the __call__ method. Intent is clear: validate if any validator in a list passes. Code length is concise and appropriately sized for the functionality. Action granularity is generally good, though the try/except/else block could be slightly clearer. Reading flow is natural with a clear progression from class definition to method implementations. The main readability concerns are the single-letter variable 'v' and the dense try/except/else block in __call__, which could benefit from a helper method or more explicit control flow. Overall, this is readable code that follows common Python patterns.
Run 2
The code is highly readable. It has a clear, flat structure with minimal nesting (only one level within the __call__ method). The class is logically organized with a single responsibility: combining multiple validators with OR semantics. Intents are clear: validators are tried in order, the first successful one returns, otherwise a ValueError is raised with an informative message. Action granularity is appropriate: each line performs one distinct operation (loop, try, call, continue, return, raise). The reading flow follows a natural progression from initialization to execution to string representation. Imports are grouped and reasonably concise, though some imported items (operator, re, Pattern, get_run_validators, set_run_validators, and_, attrs, default_if_none, NotCallableError) are unused in the snippet, slightly reducing conciseness. The exception handling is explicit, including a comment explaining why broad exception catching is intentional. Overall, the code is clean, maintainable, and easy to follow.
Run 3
The code is generally very readable. It has a flat structure with minimal nesting, and each method is concise and purposeful. The use of docstrings or comments for the try/except is absent, but the exception suppression with inline noqa comments is clear. Variable and method names like `validators` and `__call__` align with typical attrs patterns, improving intent clarity. The `if/else` in the try/except is a bit non-idiomatic but still clean and readable. Overall, a well-organized class with clear separation of concerns and consistent style.
Run 1
Code Structure: The class cleanly groups validator storage, execution, and representation, though several unused imports add clutter. Nesting: The loop and try/except/else introduce moderate but manageable nesting. Clarity of intent: The class name, method behavior, and error message clearly express that any successful validator is sufficient; however, the short name 'v' and broad exception handling obscure which failures are intentionally ignored. Code length: The implementation is concise without unnecessary logic. Action granularity: Each line generally performs one action, making execution easy to follow. Reading flow: Validation proceeds naturally from iteration to early success and then failure, with representation separated into its own method. The dense lint-suppression comment slightly interrupts readability.
Run 2
Code Structure: The class cleanly groups validator composition, execution, and representation, though several imports are unused in this snippet. Nesting: The loop and try/except/else introduce modest, manageable nesting. Clarity of intent: The class name, error message, and representation clearly communicate that any validator may satisfy the value; abbreviated names such as v, inst, and attr slightly reduce clarity. Catching every Exception obscures whether unexpected failures are intentionally treated as validation failures. Code length: The implementation is concise without unnecessary logic. Action granularity: Each line performs a distinct action, with no compressed multi-statement lines. Reading flow: Execution follows naturally from trying validators to returning on success or raising after all fail, although the stacked lint-suppression codes add visual noise.
Run 3
Code Structure: The class logically groups validation behavior and representation, though several unused imports add clutter to this snippet. Nesting: The loop and try/except introduce moderate, manageable nesting; returning on success keeps the flow simple. Clarity of intent: The class name, validators attribute, and error message clearly convey OR validation semantics, although 'v' is terse and catching every Exception leaves failure handling broad. Code length: The implementation is concise without unnecessary logic. Action granularity: Each line generally performs one action; the suppression comment is visually dense but does not obscure execution. Reading flow: Validation proceeds naturally through alternatives, returns on success, and raises after all fail. Decorator configuration and library-specific helpers require some contextual knowledge.