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, data, user, order):
for map in self.validators:
try:
map(data, user, order)
except Exception: # noqa: BLE001, PERF203, S112
continue
else:
return
key = f"None of {self.validators!r} satisfied for value {order!r}"
raise ValueError(key)
def __repr__(self):
return f"<or validator wrapping {self.validators!r}>"
Run 1
The code is fairly readable overall. The class structure is clear and purpose is evident. However, there are some issues: the variable name 'map' shadows Python's built-in function, which harms clarity; the 'data' and 'user' parameters are unused, adding ambiguity; and the bare exception with multiple noqa comments signals a complex error-handling design that isn't immediately clear. The nesting is shallow and actions are mostly one per line, but the 'None of' error message logic could be clearer. Overall, it's maintainable but could improve on naming and intent.
Run 2
The code is generally readable with clear structure and reasonable naming. It uses attrs for concise class definition and has a flat control flow within the __call__ method. The try/except/else with continue/return is slightly non-obvious but understandable. One line (f-string) is long but not excessive. The exception comment hints at intentional broad catching. Overall, it's a short, focused class with clear intent, though the loop logic in __call__ could be simplified for improved clarity.
Run 3
The code is well-structured and follows a logical organization typical of validator classes. It maintains flat nesting with a single for-loop containing a try-except-else block, making the flow easy to follow. The intent is clear: try multiple validators and raise an error only if all fail. The code is concise, avoiding unnecessary length while maintaining readability. Action granularity is appropriate, with one primary operation per line. The reading flow is natural, moving from initialization to validation logic to error handling. Minor improvements could include a more descriptive variable name than 'map' (which shadows a built-in) and slightly more descriptive error message. The use of type annotations and the context manager import are not strictly necessary for this snippet but don't detract from readability. Overall, this is maintainable and easily understandable code.
Run 1
Code Structure: The class is logically organized into validation and representation methods, but numerous unused imports add clutter. Nesting: The loop and try/except/else introduce moderate nesting, though early return keeps the logic manageable. Clarity of intent: The class name, validators attribute, and error message communicate OR-style validation; however, names such as map, data, user, order, and key obscure their roles, and map shadows a built-in. Catching every Exception makes the intended failure handling less precise. Code length: The implementation is concise, but the import list is unnecessarily long for this snippet. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: The sequence of trying validators, returning on success, and raising on total failure is natural; the dense suppression comment and ambiguous naming slightly interrupt readability.
Run 2
Code Structure: The class is logically organized, separating validation behavior from representation, though several imports are unused in this snippet. Nesting: The loop and try/except/else introduce moderate nesting but remain easy to follow. Clarity of intent: The class name, validators attribute, and error message clearly convey OR-style validation. However, data, user, order, and key are vague names, while map shadows a built-in. Catching every Exception also obscures which failures are expected validation outcomes. Code length: The implementation is concise, with little unnecessary logic, although the imports add clutter. Action granularity: Each line generally performs one action, making individual operations easy to inspect. Reading flow: The sequence naturally tries validators, returns on success, and raises when all fail. The decorator and suppression comment require some framework knowledge but do not substantially disrupt readability.
Run 3
Code Structure: The class logically groups validator execution and representation, though several unused imports add clutter. Nesting: The loop and try/except/else introduce moderate, manageable nesting. Clarity of intent: The class name and error message communicate OR-style validation, but names such as map, data, user, order, and key obscure parameter roles; map also shadows a built-in. Catching every Exception makes it unclear which failures are intended validation failures. Code length: The implementation is concise, although unnecessary imports detract from economy. Action granularity: Statements generally perform one action per line. Reading flow: Execution naturally progresses through validators, returns on success, and raises after all fail; the suppression-comment codes and vague names slightly interrupt comprehension.