Source code
import itertools
import math
from django.core.exceptions import EmptyResultSet, FullResultSet
from django.db.models.expressions import (
Case,
ColPairs,
Expression,
ExpressionList,
Func,
Value,
When,
)
from django.db.models.fields import (
BooleanField,
CharField,
DateTimeField,
Field,
IntegerField,
UUIDField,
)
from django.db.models.query_utils import RegisterLookupMixin
from django.utils.datastructures import OrderedSet
from django.utils.functional import cached_property
from django.utils.hashable import make_hashable
@Field.register_lookup
class IExact(BuiltinLookup):
lookup_name = "iexact"
prepare_rhs = False
def process_rhs(self, qn, connection):
rhs, params = super().process_rhs(qn, connection)
if params:
params = (connection.ops.prep_for_iexact_query(params[0x0]), *params[0x1:])
return rhs, params
Run 1
The code is highly readable due to its logical structure: imports are grouped by source (standard library, Django core, fields, utils), and the class definition follows a clear, single-purpose pattern. Nesting is minimal, with only one conditional block that is flat and easy to follow. Intent is explicit—customizing a database lookup with a parameter transformation for case-insensitive exact matching. Code length is concise, avoiding unnecessary boilerplate. Action granularity is appropriate: each line performs one clear operation (tuple unpacking, conditional check, parameter transformation, return). Reading flow is natural, moving from imports to class definition to method override. The only minor readability issue is the use of `0x0` and `0x1:` as index values, which is unconventional and slightly obscures intent; standard `0` and `1:` would be clearer. Overall, this is well-organized and easily scannable code.
Run 2
The code is relatively readable but has some mechanical and conceptual issues. On the positive side, the structure is straightforward, nesting is shallow, intent is clear (implementing a custom case-insensitive exact lookup), length is short, and the flow is logical. However, the use of hexadecimal indices like `params[0x0]` instead of `params[0]` is unconventional and obscures intent without any apparent benefit. The unpacking expression `(connection.ops.prep_for_iexact_query(params[0x0]), *params[0x1:])` is dense and mixes expression evaluation with tuple construction in one line, reducing clarity. The `BuiltinLookup` parent class is referenced but not imported in this snippet, which could cause runtime issues and ambiguity. Additionally, the heavy import block at the top might suggest unused or loosely related imports. Overall, the code is readable enough for someone familiar with Django internals, but the odd indexing and terse expression hinder broader clarity.
Run 3
The code is moderately readable. The imports are logically grouped but include unused or unexplained modules (e.g., itertools, math, many Django model fields), which adds noise. The class definition is clear and familiar for Django developers, but the method logic is less transparent: the line 'params = (connection.ops.prep_for_iexact_query(params[0x0]), *params[0x1:])' uses hexadecimal indexing and tuple unpacking that obscure intent, despite being concise. Action granularity is mostly good, but the expression is dense. Nesting is flat, and the overall structure is straightforward, but the low clarity of intent and redundant imports reduce readability.
Run 1
Code Structure: The lookup class and its method are logically organized, although many unused imports add clutter. Nesting: A single conditional keeps nesting shallow. Clarity of intent: The class name, lookup_name, and preparation function communicate case-insensitive exact matching, but hexadecimal indices obscure ordinary indexing, and BuiltinLookup is not defined or imported in the snippet. Code length: The implementation is concise, but the import section is disproportionately long. Action granularity: Statements generally perform one action each; the parameter assignment combines conversion, slicing, and tuple unpacking into a moderately dense expression. Reading flow: The method naturally proceeds from superclass processing to conditional parameter preparation and return, though excess imports and missing spacing before the decorated class slightly disrupt the presentation.
Run 2
Code Structure: The lookup class is logically organized, although numerous unused imports clutter this snippet. Nesting: The single conditional keeps nesting shallow. Clarity of intent: The class name, lookup_name, and method names communicate case-insensitive exact-match processing, but hexadecimal indices obscure simple indexing, and BuiltinLookup is not defined or imported in the snippet. Code length: The implementation is concise, though the import section is disproportionately long. Action granularity: Each line performs one coherent operation; the parameter transformation combines indexing, preparation, and tuple reconstruction but remains manageable. Reading flow: The method follows a natural sequence of obtaining parameters, conditionally transforming them, and returning the result. Conventional indices and removal of unused imports would improve readability.
Run 3
Code Structure: The lookup class and method are logically organized, although numerous unused imports clutter this snippet. Nesting: A single conditional keeps nesting shallow. Clarity of intent: Standard method names, the registration decorator, and lookup_name communicate purpose, but hexadecimal indices obscure ordinary indexing, and BuiltinLookup is not defined or imported in the provided code. Code length: The implementation is concise, but the import section is disproportionately long. Action granularity: Each statement performs a coherent action; the parameter transformation is compact without excessive operations. Reading flow: Processing, conditional adjustment, and return follow naturally, though the long tuple-construction line and missing blank line before the decorated class slightly reduce readability.