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 well-structured and highly readable. It uses clear class and method names, follows a logical organization, and keeps nesting shallow. Each method has a single, clear responsibility, with actions appropriately separated across lines. Type hints improve clarity and maintainability. The commented 'explained' path adds minimal complexity while preserving readability. Few minor improvements could be made, such as consolidating repetitive loader checks or simplifying mixed type annotations, but overall the code is concise, intentional, and follows a natural reading flow.
Run 3
The code is well-structured with clear separation of concerns across methods. Each method has a single responsibility and follows consistent patterns. Nesting is minimal—never exceeding two levels, which aids comprehension. The intent is clear: the class dispatches template loading across application and blueprint loaders, with separate fast and explained paths. Type hints improve clarity. However, some minor issues reduce readability: the variable naming (trv, rv, _srcobj) is cryptic, and the explicit tuple type annotations are verbose, adding visual noise. The logic in _get_source_explained is slightly tangled due to tracking both rv and trv. list_templates repeats the loader retrieval pattern from _iter_loaders, though this is likely intentional for iteration efficiency. Overall, the code is highly readable and maintainable.
Run 1
Code Structure: Well-organized class with separate methods for loader iteration, fast lookup, diagnostic lookup, and listing templates. Nesting: Generally shallow, although diagnostic lookup and template listing introduce moderate nesting. Clarity of intent: Descriptive method names, a class docstring, and type annotations communicate purpose; abbreviated variables such as rv, trv, and srcobj make diagnostic logic harder to follow. Code length: Reasonably concise, but repeated complex tuple annotations and loader traversal add verbosity; unused imports and the unused template parameter introduce clutter. Action granularity: Statements generally perform one action per line, with no compressed multi-action statements. Reading flow: Lookup dispatch and fallback behavior follow naturally, but the inline import and dense annotations interrupt the flow slightly.
Run 2
Code Structure: Well-organized class with separate methods for dispatch, diagnostics, fast lookup, loader iteration, and template listing. Nesting: Mostly shallow; the diagnostic loop and blueprint template collection introduce modest nesting. Clarity of intent: Descriptive method names, a helpful class docstring, and type annotations clarify behavior, but abbreviated names such as rv and trv obscure the diagnostic path. Code length: Generally concise, though repeated complex tuple annotations and the nested template-collection loop add avoidable verbosity. Action granularity: Each line generally performs one clear action. Reading flow: Methods follow a logical progression, with straightforward returns and exception handling; the local import slightly interrupts flow. Unused imports, an unused template parameter in _iter_loaders, and externally unresolved App and Scaffold names add minor distractions.
Run 3
Code Structure: Well-organized methods separate 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 class docstring, and type annotations clarify behavior; abbreviated variables such as rv and trv, undefined-in-snippet types App and Scaffold, and an unused template parameter reduce clarity. Code length: Generally concise, but repeated complex tuple annotations and the inner template-collection loop add avoidable verbosity. Action granularity: Statements consistently perform one action per line. Reading flow: Public dispatch followed by specialized helpers creates a natural progression, with straightforward early returns and exception handling; the local import and dense annotations slightly interrupt that flow.