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):
sqls = ["(%s)" % sql for sql in self.sqls]
return " AND ".join(sqls), list(self.params or ())
Run 1
The code is clean and readable. Structure is logical: a simple class encapsulates two data attributes and one rendering method. Nesting is flat, with only a list comprehension. Intent is clear from descriptive names ('ExtraWhere', 'sqls', 'params') and a helpful comment explaining constraints. The code is concise without unnecessary boilerplate. Action granularity is fine, with each step in 'as_sql' separated. Reading flow is natural. Minor deductions: the 'compiler' and 'connection' parameters are unused, and the comprehension could be split for clarity, but overall readability is high.
Run 2
The code is relatively clear due to good naming, concise methods, and one action per line. However, several structure and readability issues lower the score significantly. The class-level comments and attributes are logically placed, but the imports at the top are problematic: unused imports like `operator`, `reduce`, `Case`, `When`, `Mod`, `Exact`, `tree`, and `cached_property` add noise and suggest tangled organization. The `as_sql` method is flat and uses comprehensions, but the `self.params or ()` fallback is slightly cryptic — it works but assumes `None` is the only falsy value. The overall intent is clear, but the class is lightweight, so the unused imports disproportionately hurt the structural impression. The code length is concise, action granularity is good, and reading flow is natural within the method, but the lack of type hints and the dead imports make the module feel less intentional.
Run 3
The code is highly readable, with clear imports, a concise class definition, and a straightforward __init__ method. The structure is logical: the class is short and focused, with clear comments explaining key constraints. Nesting is minimal—only one level in as_sql. Intent is clear: the class wraps raw SQL fragments and parameters, combining them with AND. Code length is minimal and appropriate. Action granularity is good; each line performs one logical step, and the list comprehension is simple enough to remain readable. The reading flow is natural, moving from class description to initializer to SQL generation. Minor deductions: no type hints, the sqls variable uses plural naming slightly ambiguously, and the black-box comment could be more explicit about the caller's responsibility. Overall, the code is clean, focused, and easy to understand.
Run 1
Code Structure: The small class is logically organized, with metadata, initialization, and SQL rendering clearly separated. Nesting: The code is flat, with no nested control flow. Clarity of intent: Class and method names, together with the comment, communicate the purpose; however, abbreviated names such as sqls and the unused compiler and connection arguments require some contextual knowledge. Code length: The implementation is concise, but the many unused imports add unnecessary clutter to this snippet. Action granularity: Each statement performs a focused action; the return statement combines simple formatting and parameter normalization without becoming difficult to read. Reading flow: Execution flows naturally from storing inputs to wrapping SQL fragments and joining them with AND. Additional blank-line separation around the class would improve presentation.
Run 2
Code Structure: The small class logically groups SQL fragments, parameters, and rendering behavior, though several unused imports add clutter. Nesting: Methods are flat, with only a simple list comprehension. Clarity of intent: Descriptive names and the comment make the purpose clear; the aggregate/window flags communicate assumptions explicitly. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs a focused action, although the return expression combines joining SQL and normalizing parameters. Reading flow: Initialization followed by SQL rendering is natural and easy to follow. Minor spacing improvements and removal of unused imports would improve readability.
Run 3
Code Structure: The class is logically organized, with class attributes followed by initialization and SQL rendering. Nesting: The code is flat, with no nested control flow. Clarity of intent: Method names and the comment communicate purpose, though abbreviated names and SQL compilation conventions require some domain knowledge. Code length: The implementation is concise, but numerous unused imports add clutter. Action granularity: Each statement performs a single clear action; the list comprehension is compact and readable. Reading flow: The progression from stored inputs to formatted SQL and parameters is natural. An additional blank line before the top-level class would improve formatting.