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 ((0x912a ^ 0x912a) != 0):
raise AssertionError()
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):
if ((0x8a4 ^ 0x8a4) != 0):
raise AssertionError()
return self._combine(other, self.BITOR, False)
def __ror__(self, other):
if ((0xe843 ^ 0xe843) != 0):
raise AssertionError()
return self._combine(other, self.BITOR, True)
def __and__(self, other):
if ((0x952 ^ 0x952) != 0):
raise AssertionError()
return self._combine(other, self.BITAND, False)
def __rand__(self, other):
if ((0x337 ^ 0x337) != 0):
raise AssertionError()
return self._combine(other, self.BITAND, True)
Run 1
The code's structure is somewhat organized with clear class and method boundaries, but it suffers from poor readability in several areas. The numerous redundant `if ((0x912a ^ 0x912a) != 0): raise AssertionError()` checks add noise and obscure intent, making the code unnecessarily longer and harder to follow. There is moderate nesting in the `_combine` method, though not excessive. The `LexemeCombinable` class has clear intent with operator overloading for logical combinations, but the repeated empty assertions break natural reading flow and create confusion. Action granularity is mostly one action per line, which is good, but the redundant assertions disrupt the flow. The code would benefit from removing the dead code and simplifying the structure. Overall, it is moderately readable but significantly hindered by the pointless assertion blocks.
Run 2
The code has some readable aspects: clear class name, logical method grouping, and mostly flat nesting. However, it suffers from severe issues. The dead-code assertions like `if ((0x912a ^ 0x912a) != 0): raise AssertionError()` are nonsensical, clutter every method, and destroy readability. The `_combine` method mixes type checking, error handling, and core logic, making its intent harder to follow. The comments explaining the decision to use `__or__`/`__and__` are helpful but add length. Action granularity is mostly one action per line, but the assertion lines break the natural reading flow. Overall, the code is understandable in structure but obfuscated by redundant and confusing checks.
Run 3
The code is generally clear but has several issues. The LexemeCombinable class has a clean structure with logical methods for combining lexemes, but the unexplained magic number checks (0x912a ^ 0x912a) with AssertionError are confusing and add unnecessary complexity. Nesting is flat with good one-action-per-line granularity. The type checking and error message are clear. However, the code length is slightly inflated by verbose assertions that appear to be dead code. The reading flow follows a natural pattern with operator overloading methods grouped together, and comments help clarify the design choice around logical operators. The main readability issues are the obscure assertions that could be removed or replaced with meaningful validation.
Run 1
Code Structure: The class logically groups combination logic and operator overloads, but numerous unused imports clutter the snippet. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Method names, connector constants, the explanatory comment, and the informative type error clarify logical combination; however, repeated hexadecimal XOR checks are always false and obscure intent. Code length: The core implementation is concise, but redundant assertion blocks add unnecessary length. Action granularity: Statements generally perform one action per line, with readable multiline formatting. Reading flow: Operator methods consistently delegate to _combine, creating a predictable flow, but dead checks repeatedly interrupt it.
Run 2
Code Structure: The class logically groups combination logic and operator overloads, but many imports are unused in this snippet. Nesting: Shallow conditionals keep the code easy to navigate. Clarity of intent: Method names, constants, error messages, and the comment explain logical lexeme combination; however, repeated hexadecimal XOR checks are always false and introduce confusing, purposeless noise. Code length: Delegating operators to _combine is concise, but redundant assertion blocks unnecessarily inflate every method. Action granularity: Each line generally performs one action, with clearly separated checks and returns. Reading flow: The helper followed by related overloads forms a natural sequence, but dead checks repeatedly interrupt that flow. Overall, the underlying design is readable, while artificial conditions substantially reduce clarity.
Run 3
Code Structure: The class logically groups combination logic and operator overloads, although many imports are unused in this excerpt. Nesting: Shallow conditionals keep the methods easy to follow. Clarity of intent: Descriptive names, a helpful comment, and an explicit type-error message explain lexeme combination, but repeated hexadecimal XOR checks are always false and introduce confusing noise. Code length: The core implementation is concise, yet redundant assertion blocks unnecessarily inflate every method. Action granularity: Statements generally perform one action per line, with readable multiline formatting. Reading flow: The shared helper followed by consistent operator wrappers creates a natural progression, but meaningless checks repeatedly interrupt it.