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):
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 a clear purpose and generally logical organization, with reasonable method separation. However, it suffers from inconsistent formatting that significantly harms readability: some multi-line function calls have poor indentation (e.g., the TypeError raise and the __eq__ method), creating visual clutter. The __eq__ method is especially tangled, with awkward line breaks and alignment that obscure the comparison logic. Nesting is minimal, which is good, and action granularity is mostly one action per line in __init__ and __call__, but the formatting inconsistencies break the natural reading flow. The regex compilation line is fine, and the class attributes are clearly defined. Overall, the code is understandable but the formatting issues make it feel sloppier than it needs to be, preventing a higher score despite the logic itself being straightforward.
Run 2
The code is generally readable but has several flaws. Structure is logical with clear class and method organization, though the __eq__ method has awkward line breaks. Nesting is minimal and acceptable. Intent is mostly clear - it's a regex validator - but the TypeError message is overly verbose. Code length is reasonable; however, the multiline conditional in __eq__ could be more concise. Action granularity is mostly one action per line, but the raise TypeError statement and __eq__ return have awkward formatting with excessive whitespace. Reading flow is natural overall, but the poorly formatted lines (TypeError message, __eq__ conditions) disrupt comprehension. The docstring is helpful. Main issues are inconsistent formatting and some verbose expressions that reduce readability.
Run 3
The code is generally organized with reasonable imports and a clear class structure. The __init__ method is straightforward, though the default parameters could be simplified. The main issues are inconsistent formatting and poor action granularity. Several lines cram multiple conditions or concatenate arguments, reducing readability. The type error message and __eq__ method are awkwardly formatted with excessive indentation, making them harder to follow. The __call__ method is clear but could use blank lines between logical sections. The nesting is minimal, and intent is mostly clear, but the formatting inconsistencies break the natural reading flow. Some lines are unnecessarily long or oddly broken. Overall, the code is functional but not polished.
Run 1
Code Structure: The validator class is logically organized into configuration, initialization, validation, and equality methods, though unused imports add clutter. Nesting: Control flow is shallow, with simple conditionals and no deeply nested blocks. Clarity of intent: Descriptive names and the validation docstring make the purpose clear; the inverse-match expression requires minor interpretation. Code length: The implementation is reasonably concise, although repetitive initialization checks and unrelated imports slightly dilute it. Action granularity: Most lines perform one action, but several equality comparisons share lines, making them harder to scan. Reading flow: Method order is natural, but inconsistent spacing, awkwardly formatted expressions, and missing separation between methods interrupt readability.
Run 2
Code Structure: The class logically separates configuration, validation, and equality checks, though missing spacing between methods weakens organization. Nesting: Shallow conditionals keep execution easy to follow. Clarity of intent: Descriptive names and the validation docstring explain the purpose well; the inverse-match expression requires slight interpretation. Code length: Concise overall, with repetitive initialization checks that remain understandable. Action granularity: Most lines perform one action, but several equality conditions share awkwardly formatted lines. Reading flow: Initialization naturally precedes validation and comparison, but excessive inline whitespace and inconsistent formatting interrupt scanning. Several imports are unused in this snippet and add visual clutter.
Run 3
Code Structure: The class logically separates configuration, validation, and equality comparison, though missing spacing between methods weakens visual organization. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: Descriptive names, sensible defaults, and the validation docstring clearly communicate purpose; the inverse-match expression requires minor interpretation. Code length: Concise overall, with reasonable explicit configuration checks, although unused imports add clutter. Action granularity: Most lines perform one action, but irregular formatting packs several equality conditions onto single lines. Reading flow: Initialization naturally leads into validation and comparison, but excessive inline whitespace in the TypeError and equality expressions interrupts scanning. Consistent formatting and removal of unused imports would substantially improve readability.