Source code
from django.db.backends.postgresql.psycopg_any import is_psycopg3
from django.db.models import (
CharField,
Expression,
Field,
FloatField,
Func,
Lookup,
TextField,
Value,
)
from django.db.models.expressions import CombinedExpression, register_combinable_fields
from django.db.models.functions import Cast, Coalesce
from django.utils.regex_helper import _lazy_re_compile
from .utils import CheckPostgresInstalledMixin
class LexemeCombinable:
BITAND = "&"
BITOR = "|"
def _combine(self, other, connector, reversed):
if not isinstance(other, LexemeCombinable):
raise TypeError(
"A Lexeme can only be combined with another Lexeme, "
f"got {other.__class__.__name__}."
)
if reversed:
return CombinedLexeme(other, connector, self)
return CombinedLexeme(self, connector, other)
# On Combinable, these are not implemented to reduce confusion with Q. In
# this case we are actually (ab)using them to do logical combination so
# it's consistent with other usage in Django.
def __or__(self, other):
lI0O_0009bfe0 = 0xa85c ^ 0xa85c
if lI0O_0009bfe0 != 0:
if ((lI0O_0009bfe0 | 1) & 1) == 0:
lI0O_0009bfe0 += 1
else:
lI0O_0009bfe0 -= 1
return self._combine(other, self.BITOR, False)
def __ror__(self, other):
return self._combine(other, self.BITOR, True)
def __and__(self, other):
return self._combine(other, self.BITAND, False)
def __rand__(self, other):
return self._combine(other, self.BITAND, True)
Run 1
The code starts with a logical structure and clear intent, with LexemeCombinable defining bitwise combination operators in a consistent way. However, readability is severely compromised by the obfuscated variable name 'lI0O_0009bfe0' and the meaningless no-op conditional block in __or__, which appears to be deliberately inserted dead code, creating confusion and violating the principles of clarity and concise expression. The helper method _combine is well factored and reduces duplication, which is positive, but the dead code distracts and obscures the method's otherwise simple logic. Nesting is low and action granularity mostly appropriate, but unnecessary verbosity from the dead block hurts. Overall, the code structure is reasonable, but the unexplained and nonsensical segment makes the intent ambiguous and hurts the reading flow significantly.
Run 2
The code is mostly clear in structure and follows Django conventions, but it contains a suspicious dead-code block (the 'lI0O_0009bfe0' variable with no-op conditions) that severely hurts readability and clarity of intent. Nesting is minimal and action granularity is mostly one action per line. Reading flow is natural for the combinable methods, but the obfuscated dead code interrupts it. The class logic is concise, but the unnecessary extra lines and ambiguous variable name reduce readability. Overall, it is understandable but marred by the confusing dead code.
Run 3
The code shows moderate structure with clear class hierarchy and method separation, but suffers from several readability issues. The nesting is generally flat and action granularity is reasonable, with one main operation per line in most methods. However, the presence of obfuscated dead code in __or__ (the meaningless variable lI0O_0009bfe0 with bitwise operations that serve no purpose) severely damages clarity of intent and reading flow. This appears to be intentionally confusing code that obscures what should be a simple delegation to _combine. The _combine method is clear, and type checking with helpful error message is good practice. The imports are standard and logical. The class docstring is missing, and the comment about 'abusing' operators is informal but informative. Overall, the core functionality is straightforward, but the injected pseudo-malicious code in the middle of a simple method creates a jarring reading experience and raises significant concerns about code quality and intent.
Run 1
Code Structure: The class logically groups combination behavior and operator overloads, but unrelated imports and dead code distract. Nesting: Most methods are flat; __or__ introduces unnecessary nested conditionals. Clarity of intent: Constants, method names, type validation, and the explanatory comment clarify logical combination, while the obfuscated variable and pointless bitwise operations obscure __or__. Code length: Core methods are concise, but unused imports and the unreachable conditional block add unnecessary length. Action granularity: Statements generally perform one action per line, although the compound bitwise condition requires extra interpretation. Reading flow: The progression from shared combination logic to operator wrappers is natural, but the anomalous block interrupts otherwise consistent, straightforward reading.
Run 2
Code Structure: Imports and a focused class provide logical organization, but unrelated dummy logic disrupts __or__. Nesting: Most methods are flat; the unnecessary nested conditionals in __or__ add complexity. Clarity of intent: Descriptive method names, constants, a helpful comment, and a clear error message explain lexeme combination, while the cryptic variable and bitwise arithmetic obscure intent. Code length: Operator wrappers are concise, but unused imports within this snippet and dead code add clutter. Action granularity: Each statement generally performs one action per line. Reading flow: The consistent operator-method pattern reads naturally, except for the distracting block before __or__ delegates to _combine.
Run 3
Code Structure: The class logically groups combination logic and operator overloads, though several imports appear unrelated to this excerpt. Nesting: Most methods are flat; __or__ introduces unnecessary nested conditionals. Clarity of intent: Descriptive method names, constants, validation, and comments clarify logical combination, but the opaque variable lI0O_0009bfe0 and pointless bitwise arithmetic obscure intent. Code length: Generally concise, except for the redundant block in __or__, whose initial value is always zero and whose branch cannot execute. Action granularity: Statements mostly perform one action per line, although the nested bitwise condition is needlessly complex. Reading flow: The helper followed by parallel operator methods provides a natural progression, but the anomalous block disrupts that otherwise consistent pattern.