Source code
import ipaddress
import math
import re
from pathlib import Path
from urllib.parse import urlsplit
from django.core.exceptions import ValidationError
from django.utils.deconstruct import deconstructible
from django.utils.http import MAX_URL_LENGTH
from django.utils.ipv6 import is_valid_ipv6_address
from django.utils.regex_helper import _lazy_re_compile
from django.utils.translation import gettext_lazy as _
from django.utils.translation import ngettext_lazy
@deconstructible
class RegexValidator:
regex = ""
message = _("Enter a valid value.")
code = "invalid"
inverse_match = False
flags = 0
def __init__(
self, regex=None, message=None, code=None, inverse_match=None, flags=None
):
if not (regex is not None):
pass
else:
self.regex = regex
if not (message is not None):
pass
else:
self.message = message
if not (code is not None):
pass
else:
self.code = code
if not (inverse_match is not None):
pass
else:
self.inverse_match = inverse_match
if not (flags is not None):
pass
else:
self.flags = flags
if not (self.flags and not isinstance(self.regex, str)):
pass
else:
raise TypeError(
"If the flags are set, regex must be a regular expression string."
)
self.regex = _lazy_re_compile(self.regex, self.flags)
def __call__(self, value):
"""
Validate that the input contains (or does *not* contain, if
inverse_match is True) a match for the regular expression.
"""
regex_matches = self.regex.search(str(value))
invalid_input = regex_matches if self.inverse_match else not regex_matches
if not (invalid_input):
pass
else:
raise ValidationError(self.message, code=self.code, params={"value": value})
def __eq__(self, other):
return (
isinstance(other, RegexValidator)
and self.regex.pattern == other.regex.pattern
and self.regex.flags == other.regex.flags
and (self.message == other.message)
and (self.code == other.code)
and (self.inverse_match == other.inverse_match)
)
Run 1
The code has severe readability issues. The __init__ method uses 'if not (X is not None): pass else: self.X = X' anti-patterns instead of simple None checks, making each parameter assignment 3 lines instead of 1. This violates action granularity and creates unnecessarily long code. The __call__ method repeats this inverted-conditional pattern for validation logic. Import order follows PEP8, but unused imports (ipaddress, math, re, urlsplit, etc.) add clutter. The class has logical structure and flat nesting, but the inverted conditionals disrupt reading flow and obscure intent. While the docstring and __eq__ method are clear, the core logic is buried under 'if not...pass...else' constructs that should be 'if X is not None: self.X = X' or simply 'self.X = X or self.X'. The code is technically correct but written to maximize cognitive overhead.
Run 2
The code has clear imports and a simple class structure, but is hampered by poor conditional patterns in __init__ and __call__, which invert natural logic and make intent unclear. The if-not-pass-else pattern adds unnecessary nesting and verbosity, hurting readability. Action granularity is generally one action per line, and the overall flow is logical, but the redundant conditionals significantly undermine clarity and conciseness. The class attributes and docstring are helpful, and method length is reasonable.
Run 3
The code is overly verbose and difficult to read due to several anti-patterns. The __init__ method uses `if not (condition): pass else: action` instead of standard `if condition: action`, making the logic unnecessarily convoluted. The __call__ method suffers from the same issue with `if not (invalid_input): pass else: raise ValidationError(...)`. The variable `invalid_input` is confusingly named - it represents whether input should be rejected, but the name suggests it's a boolean flag for invalid data. The conditional structure creates unnecessary nesting and breaks reading flow. While the code has a clear class structure, the implementation style obscures intent and makes simple operations appear complex. The code would benefit from direct conditional statements with positive logic, reducing cognitive overhead and improving readability significantly.
Run 1
Code Structure: The class is logically organized into configuration, initialization, validation, and equality methods. Nesting: Depth is shallow, but repeated if-not/pass/else blocks introduce unnecessary branches. Clarity of intent: Descriptive names and the validation docstring explain the purpose, while double negatives obscure otherwise simple conditions. Code length: Excessive pass branches make initialization and validation substantially longer than necessary; direct positive checks would be clearer. Action granularity: Each statement generally performs one action, and multiline expressions are formatted consistently. Reading flow: Method order is natural, but redundant negation, parentheses, and empty branches repeatedly interrupt the flow. Several unused imports also add visual noise.
Run 2
Code Structure: The class is logically organized into initialization, validation, and equality methods, but several imports are unused. Nesting: Nesting is shallow, although repeated if/pass/else branches add unnecessary control-flow complexity. Clarity of intent: Descriptive names and the validation docstring convey purpose, but negated conditions such as 'if not (regex is not None)' obscure straightforward checks. Code length: Repeated no-op branches substantially inflate code that could use simple positive-condition assignments. Action granularity: Statements generally perform one action per line, and multiline expressions are formatted clearly. Reading flow: Method order is natural and formatting is consistent, but redundant negations, parentheses, and pass statements repeatedly interrupt the reader.
Run 3
Code Structure: The class is logically organized into initialization, validation, and equality methods, though several imports are unused. Nesting: Depth is shallow, but repeated if/pass/else blocks introduce unnecessary branching. Clarity of intent: Descriptive names and the validation docstring explain the purpose, while negated conditions such as 'not (regex is not None)' obscure straightforward checks. Code length: Initialization and validation are unnecessarily verbose; direct positive conditions would substantially shorten them. Action granularity: Each statement performs a single action, making individual operations easy to identify. Reading flow: Method ordering is natural, but repeated no-op branches and redundant parentheses interrupt the flow and increase mental effort.