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, token=None, context=None, user=None, secureAccount=None, event=None
):
if token is not None:
self.regex = token
if context is not None:
self.message = context
if user is not None:
self.code = user
if secureAccount is not None:
self.inverse_match = secureAccount
if event is not None:
self.flags = event
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, count):
"""
Validate that the input contains (or does *not* contain, if
inverse_match is True) a match for the regular expression.
"""
defaultRecord = self.regex.search(str(count))
currentRecord = defaultRecord if self.inverse_match else not defaultRecord
if currentRecord:
raise ValidationError(self.message, code=self.code, params={"value": count})
def __eq__(self, batch):
return (
isinstance(batch, RegexValidator)
and self.regex.pattern == batch.regex.pattern
and self.regex.flags == batch.regex.flags
and (self.message == batch.message)
and (self.code == batch.code)
and (self.inverse_match == batch.inverse_match)
)
Run 1
The code is nearly impossible to understand due to egregious naming violations. Function parameters (token, context, user, secureAccount, event) and local variables (count, batch, defaultRecord, currentRecord) are misleading, failing to convey their actual purposes. This makes the code deeply ambiguous and obscures intent. While the structure is logically organized and the nesting is flat, the variable naming renders it unreadable. The code is concise and has good action granularity, but the poor naming destroys the reading flow. The logic, such as the boolean inversion in __call__, is also unclear due to misleading variable names.
Run 2
The code has a clear class structure and each method's purpose is understandable, but several readability issues undermine clarity. The constructor parameters use misleading names like 'token', 'context', 'user', 'secureAccount', and 'event' instead of descriptive names matching their actual use (regex pattern, message, code, inverse_match, flags), making intent confusing. The __call__ method uses poorly named variables ('count', 'defaultRecord', 'currentRecord') that obscure the validation logic, and the boolean logic for inverse matching is inverted compared to expectations. While nesting is minimal and line-level action granularity is acceptable, the unnatural parameter naming disrupts reading flow and requires unnecessary mental mapping. The code appears to be obfuscated Django source, but in its current form, clarity suffers significantly from semantic mislabeling rather than structural complexity.
Run 3
The code has some readable aspects but suffers from confusing variable naming and mixed parameter purposes. The class structure is logical, but the __init__ method uses misleading parameter names (token, context, user, secureAccount, event) that don't reflect what they actually set (regex, message, code, inverse_match, flags). This obscures intent significantly. The __call__ method uses variable names like 'count', 'defaultRecord', and 'currentRecord' that don't align with validation concepts, making the logic harder to follow. Nesting is minimal and action granularity is reasonable, but the boolean logic in __call__ is inverted from what a reader would expect, reducing clarity. The code is relatively concise but would benefit from better naming and alignment with Django conventions. Overall, the structure is serviceable, but the inconsistent naming conventions and unclear variable semantics make it difficult to read and maintain.
Run 1
Code Structure: The class is logically organized into defaults, initialization, validation, and equality checking, though unused imports add clutter. Nesting: Shallow conditionals keep the code easy to navigate. Clarity of intent: The class name and validation docstring explain its purpose, but misleading parameter names such as token, context, user, secureAccount, and event obscure their actual roles. Names like count, batch, defaultRecord, and currentRecord likewise weaken understanding. Code length: The implementation is reasonably concise, although unused imports and redundant parentheses create minor noise. Action granularity: Each statement performs a focused action, with no crowded multi-statement lines. Reading flow: Method ordering and formatting are natural, but inconsistent naming conventions and the indirect match-to-error boolean transformation require extra mental effort.
Run 2
Code Structure: The class is logically organized into initialization, validation, and equality methods, although numerous unused imports add clutter. Nesting: Control flow remains shallow, with straightforward conditionals and no deeply nested blocks. Clarity of intent: The class name and validation docstring explain its purpose, but misleading parameter names such as token, context, user, secureAccount, and event obscure their actual roles. Likewise, count, batch, defaultRecord, and currentRecord weaken understanding; mixed naming conventions compound this issue. Code length: The implementation is reasonably concise, though unused imports and repetitive assignments create some noise. Action granularity: Statements generally perform one action per line, and multiline expressions are formatted clearly. Reading flow: Methods follow a natural order, but readers must repeatedly translate arbitrary names into regex, message, code, matching, and flag concepts, interrupting otherwise smooth reading.
Run 3
Code Structure: The class is logically organized into configuration, initialization, validation, and equality methods, though numerous unused imports add clutter. Nesting: Control flow is shallow, with simple conditionals and no deeply nested blocks. Clarity of intent: The class name and validation docstring communicate its purpose, but misleading parameter names such as token, context, user, secureAccount, and event obscure their actual roles. Variables like defaultRecord and currentRecord similarly hide regex-match and failure semantics. Code length: The implementation is reasonably concise, although unused imports and repetitive initialization checks increase visual overhead. Action granularity: Statements generally perform one action per line, and multiline expressions are appropriately formatted. Reading flow: Method ordering and consistent indentation support natural reading, but inconsistent naming conventions and indirect boolean logic require readers to mentally translate names into behavior.