Source code
from __future__ import annotations
import typing as t
from jinja2 import BaseLoader
from jinja2 import Environment as BaseEnvironment
from jinja2 import Template
from jinja2 import TemplateNotFound
from .ctx import AppContext
from .globals import app_ctx
from .helpers import stream_with_context
from .signals import before_render_template
from .signals import template_rendered
class DispatchingJinjaLoader(BaseLoader):
"""A loader that looks for templates in the application and all
the blueprint folders.
"""
def __init__(self, app: App) -> None:
self.app = app
def get_source(
self, environment: BaseEnvironment, template: str
) -> tuple[str, str | None, t.Callable[[], bool] | None]:
if self.app.config["EXPLAIN_TEMPLATE_LOADING"]:
return self._get_source_explained(environment, template)
return self._get_source_fast(environment, template)
def _get_source_explained(
self, environment: BaseEnvironment, template: str
) -> tuple[str, str | None, t.Callable[[], bool] | None]:
attempts = []
rv: tuple[str, str | None, t.Callable[[], bool] | None] | None
trv: None | (tuple[str, str | None, t.Callable[[], bool] | None]) = None
for srcobj, loader in self._iter_loaders(template):
try:
rv = loader.get_source(environment, template)
if trv is None:
trv = rv
except TemplateNotFound:
rv = None
attempts.append((loader, srcobj, rv))
from .debughelpers import explain_template_loading_attempts
explain_template_loading_attempts(self.app, template, attempts)
if trv is not None:
return trv
raise TemplateNotFound(template)
def _get_source_fast(
self, environment: BaseEnvironment, template: str
) -> tuple[str, str | None, t.Callable[[], bool] | None]:
for _srcobj, loader in self._iter_loaders(template):
try:
return loader.get_source(environment, template)
except TemplateNotFound:
continue
raise TemplateNotFound(template)
def _iter_loaders(self, template: str) -> t.Iterator[tuple[Scaffold, BaseLoader]]:
loader = self.app.jinja_loader
if loader is not None:
yield self.app, loader
for blueprint in self.app.iter_blueprints():
loader = blueprint.jinja_loader
if loader is not None:
yield blueprint, loader
def list_templates(self) -> list[str]:
result = set()
loader = self.app.jinja_loader
if loader is not None:
result.update(loader.list_templates())
for blueprint in self.app.iter_blueprints():
loader = blueprint.jinja_loader
if loader is not None:
for template in loader.list_templates():
result.add(template)
return list(result)
Run 1
The code is generally well-structured and readable. It follows a clean class-based approach with clear separation of concerns (explained vs fast loading paths). Functions are small and focused with descriptive names. The nesting level is shallow (maximum 2-3 levels), and the flow from public method to private helpers is logical. Type hints improve clarity significantly. The main weaknesses are: (1) the complex tuple type annotations create noise and potential maintenance burden - extracting a type alias would improve readability; (2) the `_get_source_explained` method has slightly convoluted logic with `rv` and `trv` variables that could use clearer naming; (3) some lines with type unions are quite long. Overall, the code demonstrates good practices like single responsibility, consistent error handling, and readable iteration patterns.
Run 2
The code is generally well-structured and readable. It imports explicitly, uses type hints consistently, and separates concerns cleanly across methods. The class has a clear single responsibility: dispatching template loading across app and blueprint loaders. Method names like `_get_source_fast` and `_get_source_explained` clearly convey intent. Nesting is shallow, and action granularity is appropriate—each line typically performs one operation. The `_get_source_explained` method is slightly more complex due to tracking both `rv` and `trv`, which adds mild cognitive overhead. The `_iter_loaders` method is clean and reusable. Overall, the code favors clarity over cleverness, with good balance between verbosity and explicitness. Minor deductions come from the slight redundancy in `_get_source_explained` and the somewhat dense type annotations in the return signatures.
Run 3
The code is generally well-structured and readable. It uses clear class and method names, separates concerns into distinct methods (`_get_source_explained`, `_get_source_fast`, `_iter_loaders`), and maintains flat nesting with only one or two levels of indentation in most places. Type hints are used consistently, improving clarity of intent. The loading strategy pattern is cleanly separated. Minor deductions: the `_get_source_explained` method has slightly awkward variable annotations (`rv`, `trv`) that could be clearer, and the tuple return type is repeated verbatim several times, adding visual noise. The `list_templates` method duplicates the loader iteration pattern rather than reusing `_iter_loaders`, which slightly reduces consistency. Overall, the code is easy to follow with logical organization and natural reading flow.
Run 1
Code Structure: Methods cleanly separate loader dispatch, diagnostic loading, fast loading, and template listing. Nesting: Mostly shallow, although diagnostic loading and blueprint template listing reach three levels. Clarity of intent: Descriptive method names, a class docstring, and type annotations establish the purpose; abbreviated variables such as rv, trv, and srcobj reduce clarity, while App and Scaffold lack visible definitions or imports. Code length: Generally concise, but repeated complex return annotations and duplicated loader traversal add verbosity. Action granularity: Statements perform one action per line, with no compressed compound operations. Reading flow: Public dispatch leads naturally into implementation helpers, and exception handling is straightforward. The local debug import slightly interrupts flow, and unused imports and the unused template parameter add distraction.
Run 2
Code Structure: Well organized into focused methods for loader selection, diagnostic loading, fast loading, and template listing. Nesting: Mostly shallow, though diagnostic exception handling and template listing introduce moderate nesting. Clarity of intent: Descriptive method names, a class docstring, and type annotations explain the purpose; abbreviated names such as rv and trv obscure intermediate results, and App and Scaffold are not defined or imported in the snippet. Code length: Generally concise, but repeated complex return annotations and the inner loop in list_templates add avoidable verbosity. Action granularity: Each line generally performs one clear action, with no compressed multi-statement lines. Reading flow: Execution follows a natural progression from dispatch to implementation and loader iteration; the local import and dense annotations slightly interrupt that flow.
Run 3
Code Structure: Well-organized class with separate methods for dispatch, diagnostic loading, fast loading, loader iteration, and template listing. Nesting: Mostly shallow, although diagnostic loading and blueprint template collection introduce moderate nesting. Clarity of intent: Descriptive method names, a useful class docstring, and type annotations clarify behavior; abbreviated variables such as rv and trv and unexplained App and Scaffold types reduce clarity. Code length: Generally concise, but repeated complex tuple annotations and the inner template-addition loop add avoidable verbosity. Action granularity: Each line generally performs one action, making operations easy to follow. Reading flow: Dispatch precedes implementation details, and control flow is natural; the mid-method import and inconsistent annotation style slightly interrupt reading.