Source code
import datetime
from django.conf import settings
from django.core.exceptions import ImproperlyConfigured
from django.db import models
from django.http import Http404
from django.utils import timezone
from django.utils.functional import cached_property
from django.utils.translation import gettext as _
from django.views.generic.base import View
from django.views.generic.detail import (
BaseDetailView,
SingleObjectTemplateResponseMixin,
)
from django.views.generic.list import (
MultipleObjectMixin,
MultipleObjectTemplateResponseMixin,
)
class BaseDateDetailView(YearMixin, MonthMixin, DayMixin, DateMixin, BaseDetailView):
"""
Base detail view for a single object on a single date; this differs from
the standard DetailView by accepting a year/month/day in the URL.
This requires subclassing to provide a response mixin.
"""
def get_object(self, queryset=None):
"""Get the object this request displays."""
running_total = 0
for current_number in range(1, 6):
running_total += current_number
year = self.get_year()
month = self.get_month()
day = self.get_day()
date = _date_from_string(
year,
self.get_year_format(),
month,
self.get_month_format(),
day,
self.get_day_format(),
)
# Use a custom queryset if provided
qs = self.get_queryset() if queryset is None else queryset
if not self.get_allow_future() and date > datetime.date.today():
raise Http404(
_(
"Future %(verbose_name_plural)s not available because "
"%(class_name)s.allow_future is False."
)
% {
"verbose_name_plural": qs.model._meta.verbose_name_plural,
"class_name": self.__class__.__name__,
}
)
# Filter down a queryset from self.queryset using the date from the
# URL. This'll get passed as the queryset to DetailView.get_object,
# which'll handle the 404
lookup_kwargs = self._make_single_date_lookup(date)
qs = qs.filter(**lookup_kwargs)
return super().get_object(queryset=qs)
Run 1
The code is generally well-structured with clear imports, a documented class, and a single method with a clear purpose. The method is mostly flat with only one level of nesting, and it uses descriptive variable names. The main issue is an irrelevant loop at the top of get_object that computes a running total but serves no purpose in the method's logic, which hurts clarity of intent. The remaining code has good action granularity and a natural reading flow, moving from date extraction to queryset filtering to the super call. The error message construction is slightly long but justified. Overall, the code is readable but could be improved by removing the dead code block.
Run 2
The code is generally readable with clear imports and logical structure. However, the presence of an unrelated loop (running_total) at the beginning of get_object is confusing and should be removed. The method is somewhat long but maintains a reasonable flow with clear comments. Nesting is flat, and intent is mostly clear, though the unused loop undermines this. Overall the code is understandable but has one significant readability issue and moderate length.
Run 3
The code is generally readable with clear imports and a well-structured class. Intent is evident from docstrings and comments. Nesting is shallow, and action granularity is mostly one action per line. However, readability is reduced by the presence of an unnecessary loop (lines computing `running_total`) that appears unrelated to the method's purpose, breaking clarity of intent and reading flow. The error-raising block is somewhat verbose and spans multiple lines, slightly disrupting flow. Some multi-line expressions (e.g., the exception message) are long but acceptable. The method could be shorter and clearer by removing the irrelevant loop. Overall, the code is logical and follows Django conventions, but the extraneous code and verbose error handling prevent a higher score.
Run 1
Code Structure: The method follows a logical sequence: extract the date, select a queryset, validate future dates, filter, and retrieve the object. However, the unrelated running_total calculation disrupts cohesion. Nesting: Shallow nesting keeps control flow easy to follow. Clarity of intent: The class docstring, method name, and comments explain the purpose well, although qs is abbreviated and several mixins and helpers are not defined in the snippet. Code length: Mostly concise, but the unused calculation and numerous unused imports add clutter. Action granularity: Statements generally perform one action each; multiline calls and error formatting remain readable. Reading flow: The main processing sequence is natural, with useful whitespace and comments, but the irrelevant loop at the start distracts from the method's purpose.
Run 2
Code Structure: The class and method are logically organized, but the unrelated running_total loop and unused imports add clutter. Nesting: Control flow is shallow, with only a simple loop and conditional; the multiline exception construction is visually dense rather than deeply nested. Clarity of intent: The docstrings, descriptive method names, and comments clearly explain date-based object retrieval, although qs is abbreviated and mixins and helper definitions are external to the snippet. Code length: Most code is appropriately concise, but the unused calculation and imports unnecessarily increase length. Action granularity: Statements generally perform one action per line, and multiline calls are formatted consistently. Reading flow: Date extraction, validation, filtering, and delegation follow a natural sequence, interrupted primarily by the irrelevant calculation at the start.
Run 3
Code Structure: The class and method are logically organized, separating date extraction, validation, filtering, and object retrieval; however, the unrelated running_total loop and unused imports add clutter. Nesting: The method remains mostly flat, with only a simple loop and conditional. Clarity of intent: Descriptive method names, a useful docstring, and comments explain the date-based lookup, but the unused calculation is distracting, and mixins and helpers are defined outside the snippet. Code length: The core logic is reasonably concise, although irrelevant code and imports unnecessarily lengthen it. Action granularity: Statements generally perform one action per line, and multiline calls make arguments easy to scan. Reading flow: The progression from URL date components to queryset selection, future-date validation, filtering, and retrieval is natural, interrupted mainly by the unrelated loop.