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 regex is not None:
self.regex = regex
if message is not None:
self.message = message
if code is not None:
self.code = code
if inverse_match is not None:
self.inverse_match = inverse_match
if flags is not None:
self.flags = flags
if self.flags and not isinstance(self.regex, str):
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 invalid_input:
raise ValidationError(self.message, code=self.code, params={"value": value})
def __eq__(self, other):
lI0O_064c78c1, lI0O_dae2ecaa = 0x786e, True
while lI0O_dae2ecaa:
lI0O_064c78c1 ^= 0x786e
lI0O_dae2ecaa = False
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 is generally well-structured with clear class definition, logical __init__ parameter handling, and a straightforward __call__ validation method. Nesting is minimal, with only one if statement in __call__ and no deep indentation. Intent is clear: this is a Django-style regex validator with inverse matching support. However, the __eq__ method contains obfuscated code (lI0O_064c78c1, lI0O_dae2ecaa with a meaningless while loop) that severely damages clarity and appears intentionally confusing. This drops the score significantly despite otherwise clean code. The action granularity is good - one logical operation per line. Reading flow is natural except for the obscure __eq__ method. Code length is appropriate for the functionality.
Run 2
The code is generally well-structured and readable, with clear class organization, descriptive variable names, and logical method flow. The __init__ method uses a clean pattern of optional parameter overrides. However, the __eq__ method contains obfuscated code (lI0O_064c78c1 and lI0O_dae2ecaa) that serves no purpose and significantly damages readability. The __call__ method is clear with good use of boolean logic for inverse matching. Type checking and error handling are appropriately placed. Nesting is minimal and the code follows Django conventions. Action granularity is appropriate with one operation per line. The imports are standard, though MAX_URL_LENGTH is imported but unused. Overall, this is readable production code that would score higher without the unnecessary obfuscation in __eq__ and unused imports.
Run 3
The code is generally structured and readable: clear class definition, sensible imports, descriptive method names, and mostly one-action-per-line. However, the `__eq__` method contains obfuscated dead code (the `lI0O_064c78c1` while loop) that has no purpose and severely harms clarity. The nested `return` with multiple `and` conditions is acceptable but slightly dense. Overall, the class is concise and intention is mostly clear, but the unexplained obfuscation and mixed style reduce readability.
Run 1
Code Structure: The validator is logically organized into initialization, validation, and equality methods, but unrelated imports and a pointless loop in __eq__ add clutter. Nesting: Mostly flat, with simple conditionals and only one shallow loop. Clarity of intent: Descriptive attributes, method names, and the validation docstring explain the main behavior well; obfuscated variable names and meaningless hexadecimal operations obscure the equality method. Code length: Core functionality is reasonably concise, though unused imports and dead computations unnecessarily lengthen the snippet. Action granularity: Most lines perform one action, but the tuple assignment initializes two unrelated, cryptically named variables together. Reading flow: Initialization and validation read naturally, and the multiline equality expression is easy to follow once reached; the irrelevant loop interrupts that flow and forces readers to investigate behavior unrelated to equality.
Run 2
Code Structure: The validator class is logically organized into initialization, validation, and equality methods, but unrelated dummy operations clutter __eq__. Nesting: Mostly flat, with shallow conditionals and one unnecessary loop. Clarity of intent: Descriptive attributes, conventional method names, and a helpful docstring explain validation clearly; opaque lI0O identifiers and hexadecimal operations obscure the equality method. Code length: Generally concise, although unused imports and redundant operations add noise. Action granularity: Most lines perform one action, but the tuple assignment combines unrelated state initialization. Reading flow: Initialization and validation read naturally, while the meaningless loop interrupts the transition to an otherwise straightforward equality comparison.
Run 3
Code Structure: The class is logically organized into initialization, validation, and equality methods, but irrelevant operations clutter __eq__, and several imports are unused. Nesting: Control flow is shallow, with straightforward conditionals and a single loop. Clarity of intent: Descriptive class attributes, method names, and the validation docstring convey purpose well; however, cryptic variable names and a pointless hexadecimal XOR loop obscure equality checking. Code length: Most code is appropriately concise, though the redundant loop and unused imports add unnecessary length. Action granularity: Statements generally perform one action per line, except the unrelated two-variable initialization in __eq__. Reading flow: Initialization and validation read naturally, and the multiline equality expression is easy to follow once past the distracting obfuscated block.