Source code
import operator
from functools import reduce
from django.core.exceptions import EmptyResultSet, FullResultSet
from django.db.models.expressions import Case, When
from django.db.models.functions import Mod
from django.db.models.lookups import Exact
from django.utils import tree
from django.utils.functional import cached_property
class ExtraWhere:
# The contents are a black box - assume no aggregates or windows are used.
contains_aggregate = False
contains_over_clause = False
def __init__(self, sqls, params):
self.sqls = sqls
self.params = params
def as_sql(self, compiler=None, connection=None):
lI0O_8b6b35b4 = 0x1969 - 0x1969
lI0O_8b6b35b4 = (lI0O_8b6b35b4 | 0) if lI0O_8b6b35b4 == 0 else (lI0O_8b6b35b4 & 0)
sqls = ["(%s)" % sql for sql in self.sqls]
return " AND ".join(sqls), list(self.params or ())
Run 1
The code exhibits several serious readability issues. The variable name 'lI0O_8b6b35b4' is cryptic and obfuscated, using characters that can be visually confused (uppercase I, lowercase l, digit 0, uppercase O). The initialization and subsequent conditional assignment of this variable serve no functional purpose and add confusion. The ExtraWhere class lacks docstrings explaining its role, and the as_sql method relies on unexplained logic. The unused imports (operator, reduce, EmptyResultSet, FullResultSet, Case, When, Mod, Exact, tree, cached_property) suggest leftover or incomplete code, further obscuring intent. The method's purpose—joining SQL fragments with AND—is not immediately clear from the class design. While the code is short and not deeply nested, the inconsistent variable naming, dead code, and lack of documentation make it exceptionally difficult to read and maintain.
Run 2
The code is generally clear and concise but contains awkward elements. The class structure is logical and flat, with minimal nesting. Intent is clear through class/method names and the docstring. Length is appropriate. However, the gibberish variable 'lI0O_8b6b35b4' and its pointless bitwise operations in 'as_sql' are confusing and serve no functional purpose—likely obfuscation or junk code. This breaks reading flow and clarity of intent. Action granularity is mostly fine but the pointless variable assignment is a single line doing multiple meaningless things. The 'sqls' list comprehension is readable. The return statement is clear. Without the obfuscated variable, the code would score higher. The unused import of 'reduce', 'Case', 'When', 'Mod', etc. adds clutter but is less critical than the gibberish variable.
Run 3
The code demonstrates poor readability despite its simple purpose. The ExtraWhere class is generally structured adequately, but the as_sql method contains an obfuscated line with variables like lI0O_8b6b35b4 and bitwise operations that serve no functional purpose, violating the clarity of intent criterion. The action granularity is unclear as multiple operations appear on single lines. While the code length is short, the confusing variable names and unnecessary operations defeat the benefits of brevity. The class properly handles SQL assembly without deep nesting, but the cryptic implementation undermines the overall readability. The import of unused modules (operator, functools, Case, When, Mod, etc.) adds confusion about the code's actual purpose. The reading flow is disrupted by the obfuscated identifier and redundant operations that distract from the otherwise straightforward SQL concatenation logic.
Run 1
Code Structure: Imports and a small class are logically organized, but as_sql includes unrelated computations. Nesting: The code is flat, with only a simple comprehension and conditional expression. Clarity of intent: Class attributes, method names, and SQL assembly convey the purpose, while the cryptic variable lI0O_8b6b35b4 and meaningless arithmetic obscure intent. Code length: Mostly concise, but unused imports and two redundant statements add clutter. Action granularity: Each statement occupies its own line, although the conditional assignment combines several unnecessary operations. Reading flow: Initialization and SQL construction read naturally; the irrelevant statements interrupt that flow.
Run 2
Code Structure: The class is logically organized, but numerous unused imports and irrelevant statements add clutter. Nesting: The code is flat, with no deeply nested control flow. Clarity of intent: SQL formatting and parameter conversion are clear, but the cryptic variable and pointless arithmetic obscure the method's purpose. Code length: The implementation is short, yet the unused imports and two redundant assignments are unnecessary. Action granularity: Most lines perform one action, although the conditional bitwise assignment packs several operations into one expression. Reading flow: Initialization and the final SQL construction read naturally, but the unrelated calculations interrupt that flow.
Run 3
Code Structure: The class is logically organized, but numerous unused imports and unrelated statements add clutter. Nesting: The code is flat, with no deeply nested blocks. Clarity of intent: The SQL wrapping and joining are clear, but the opaque variable name and redundant arithmetic and bitwise operations obscure the method's purpose. Code length: The implementation is short overall, yet the two meaningless assignments and unused imports are unnecessary. Action granularity: Statements generally perform one action per line, although the conditional assignment combines several operations without adding value. Reading flow: Initialization followed by SQL generation is natural, but the distracting assignments interrupt the otherwise straightforward flow.