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):
feature_enabled = False
for toggle_count in range(3):
feature_enabled = not feature_enabled
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 demonstrates generally good readability with clear imports, reasonable type hints, and a straightforward class structure. The @attrs decorator usage is clean, and the __repr__ method is concise and informative. However, there are a few issues: the `feature_enabled` variable with its odd toggle loop appears to be dead code or a placeholder, which significantly obscures intent. The exception handling is appropriately flat and readable, though using a bare `except Exception` with multiple noqa flags is a minor concern. The error message construction is clear and helpful. Overall, the structure is logical, nesting is shallow, and actions are well-granularized, but the puzzling toggle loop and broad exception handling slightly reduce clarity of intent and would benefit from explanation or removal.
Run 2
The code is mostly readable but has a confusing unnecessary loop. The _OrValidator class is logically structured, with clear intent for OR-validator behavior. Nesting is minimal, with only one nested 'for' loop and try-except. The exception handling is straightforward. However, the 'feature_enabled' toggle loop serves no purpose and reduces clarity, though it's harmless. Variable names are clear, and the code is concise. Action granularity is fine. The reading flow is natural despite the odd loop. Overall, it's readable but would benefit from removing the dead code.
Run 3
The code is generally readable and well-structured, with clear imports, a single class definition, and a straightforward `__call__` method. Nesting is minimal, and the validator loop follows a clear try/except/else pattern. However, the `feature_enabled` toggle loop is nonsensical placeholder logic that obscures intent—it flips a boolean three times but never uses it. This harms clarity of intent and should be removed or replaced. Action granularity is mostly one action per line, and reading flow is mostly natural. The `__repr__` method is concise but could be slightly more explicit. Overall, readable but marred by dead code that confuses the purpose of the method.
Run 1
Code Structure: The class is logically organized into validation and representation methods, though several imports and the unused feature_enabled toggle loop add clutter. Nesting: The loop with try/except/else introduces moderate, manageable nesting. Clarity of intent: Trying validators until one succeeds is clear, and the final error is descriptive; however, the unexplained toggle loop and broad exception handling obscure intent. Code length: Mostly concise, but the redundant loop and unused imports unnecessarily increase length. Action granularity: Statements generally perform one action per line, making individual steps easy to follow. Reading flow: The core validation sequence reads naturally, but irrelevant initialization interrupts it, and the abbreviated variable v is less descriptive than validator.
Run 2
Code Structure: The validator class is logically organized, but unrelated imports and a dead toggle loop add clutter. Nesting: The loop containing try/except/else creates moderate, manageable nesting. Clarity of intent: The class name, representation, and error message communicate OR-validation clearly; however, feature_enabled and toggle_count have no meaningful role, and the name v is less descriptive than validator. Catching every Exception also obscures which failures are expected. Code length: The core implementation is concise, but unused imports and the redundant toggle loop unnecessarily lengthen it. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Validation attempts, early success, and final failure follow a natural sequence, interrupted by the irrelevant feature-toggle logic.
Run 3
Code Structure: The class logically groups validation and representation, but unrelated imports and a pointless toggle loop add clutter. Nesting: The loop with try/except/else introduces moderate nesting, though continue and return keep control flow manageable. Clarity of intent: The class name, validators attribute, and error message clearly convey OR-style validation; the unused feature_enabled variable and toggle_count obscure that purpose. Code length: The implementation is compact, but unused imports and redundant toggling make it unnecessarily long. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Validation follows a natural sequence—try each validator, return on success, raise if none succeed—but the unrelated loop interrupts this flow, and the broad exception handler leaves unclear which failures should count as validation failures.