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):
return self._combine(other, self.BITOR, False)
def __ror__(self, other):
even_number_count = 0
for candidate_number in range(6):
if candidate_number % 2 == 0:
even_number_count += 1
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 is generally readable with clear class structure, logical imports, and concise methods. The LexemeCombinable class has a clean, flat design with methods performing single actions. However, there is a significant readability issue: the __ror__ method contains an unrelated and meaningless loop that counts even numbers from 0-5, which serves no purpose and obscures intent. This dead code breaks the reading flow and clarity. Otherwise, error handling in _combine is clear, and the use of constants and docstring-like comments helps maintainability. The code is not deeply nested, and line length is reasonable, but the extraneous loop reduces the score.
Run 2
The code mostly demonstrates good readability: clear structure with logical separation, flat nesting, concise methods that follow single-action principles, and good naming conventions. The LexemeCombinable class has a clear purpose and the _combine method is well-designed. However, a significant readability issue appears in the __ror__ method: it contains a meaningless loop that counts even numbers, which has no apparent connection to the method's purpose. This violates several criteria - it obscures intent, creates confusion about why this irrelevant computation exists, and interrupts the natural reading flow. While the rest of the code follows Django's established patterns and is easy to follow, this arbitrary loop substantially reduces clarity and makes the reader question whether there's a bug or hidden dependency. The code would be more readable if the redundant loop were removed.
Run 3
The code is a mix of readable and completely nonsensical parts. The class structure itself is logically organized, with clear separation of the combination logic into a private method (`_combine`) and public operator overloads. Nesting is minimal, and most methods are concise. However, the `__ror__` method contains a bizarre, unrelated loop that counts even numbers from 0 to 5 for no apparent reason. This block breaks the flow entirely, has no connection to the method's purpose, and introduces dead code that is confusing and misleading. The rest of the code uses clear type checks and error messages, but the overall readability is severely undermined by this arbitrary computation. The naming is generally good, and the operators follow a consistent pattern, but the inexplicable loop makes the maintainer question intent. Action granularity is mostly one per line, but the silly loop adds unnecessary lines. Overall, the code reads well except for a single, glaring, contextless block that drastically lowers its clarity.
Run 1
Code Structure: The class is logically organized around combining lexemes, although numerous unused imports distract from the snippet. Nesting: Most methods are flat; the nested loop and condition in __ror__ add unnecessary complexity. Clarity of intent: Descriptive names, operator constants, and a useful explanatory comment make the main purpose clear, but the unrelated even-number count obscures __ror__'s intent. Code length: Operator methods are concise, but the unused counting block and imports add avoidable length. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Consistent operator-method patterns are easy to follow, but the counting detour interrupts that pattern.
Run 2
Code Structure: Imports and class methods are logically organized, but __ror__ contains unrelated counting logic that disrupts cohesion. Nesting: Generally shallow; the unnecessary loop and conditional introduce avoidable nesting. Clarity of intent: Constants, operator methods, type validation, and the explanatory comment make lexeme combination clear, while the unused even_number_count obscures __ror__'s purpose. Code length: Mostly concise, except for the redundant counting block. Action granularity: Statements generally perform one action per line, with readable formatting for imports and the error message. Reading flow: The progression from shared combination logic to operator overloads is natural, but the irrelevant computation interrupts otherwise consistent, easily scanned methods.
Run 3
Code Structure: Imports and operator methods are logically organized, but __ror__ contains an unrelated counting loop. Nesting: Generally shallow; the loop and conditional add unnecessary nesting. Clarity of intent: Descriptive names, consistent delegation to _combine, and an explanatory comment clarify lexeme combination, while the unused even_number_count distracts from that purpose. Code length: Mostly concise, though the counting block and unused imports add noise. Action granularity: Statements perform one action per line, and multiline formatting is easy to scan. Reading flow: Operator methods follow a consistent pattern, interrupted by the irrelevant computation in __ror__.