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 with clear separation into fast and explained loading paths, and the class docstring explains its purpose. Type hints improve clarity, and the methods are logically ordered. Nesting is shallow, with only one or two levels in loops and conditionals. However, readability is slightly reduced by redundant type annotations (e.g., `rv` and `trv` declarations), a mixed use of `_srcobj` and `srcobj`, and the long union type repeated several times. The `list_templates` method contains some repetition that could be extracted. Overall the flow is natural and intent is mostly clear, but a few minor inconsistencies and verbosity from type hints keep it from being highly readable.
Run 3
The code is generally well-structured and readable. It uses clear class and method names, follows a logical flow, and keeps actions mostly granular. The separation of 'explained' and 'fast' paths is clear, and the helper iterator reduces duplication. However, there are minor issues: the variable names 'rv' and 'trv' are opaque, especially around None handling; the type annotation for 'trv' is awkwardly written and slightly hurts clarity near the top of '_get_source_explained'. The nested try/except and conditional logic is acceptable but adds a small amount of complexity. Overall, it is understandable with moderate effort, but not perfectly self-documenting.
Run 1
Code Structure: Methods logically separate loader dispatch, diagnostic loading, fast loading, and template listing. Nesting: Generally shallow, although diagnostic loading and blueprint template listing introduce moderate nesting. Clarity of intent: Descriptive method names and the class docstring explain the purpose, but abbreviations such as rv, trv, and srcobj obscure meaning; App and Scaffold are not defined or imported in this snippet. Code length: Reasonably concise, though repeated complex type annotations and loader traversal add verbosity, and several imports are unused. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: The progression from public dispatch to implementation helpers is natural, with clear early returns and exception handling. The local debug import and dense annotations slightly interrupt that flow.
Run 2
Code Structure: Well organized into focused methods for loader iteration, fast lookup, diagnostic lookup, and template listing. Nesting: Mostly shallow; the diagnostic try/if and template-listing loops add modest depth. Clarity of intent: Descriptive method names, a useful class docstring, and type annotations clarify behavior, but rv/trv are opaque, App and Scaffold lack visible imports, and _iter_loaders accepts an unused parameter. Code length: Generally concise, though repeated complex tuple annotations and the explicit template-addition loop introduce avoidable verbosity. Action granularity: Each statement performs a distinct action, with no compressed multi-action lines. Reading flow: Dispatch followed by lookup implementations and supporting methods creates a natural progression; the mid-method import and dense annotations cause minor interruptions.
Run 3
Code Structure: Methods cleanly separate dispatch, diagnostic loading, fast loading, loader iteration, and template listing. Nesting: Generally shallow, although diagnostic loading and blueprint template listing introduce several nested levels. Clarity of intent: Descriptive method names, a class docstring, and type annotations clarify behavior; abbreviated variables such as rv and trv obscure their roles, and App and Scaffold lack visible imports. Code length: Mostly concise, but repeated complex tuple annotations add visual noise, and template listing could use result.update consistently. Action granularity: Each line generally performs one action, with no compressed statements. Reading flow: Public dispatch followed by implementation helpers creates a natural progression; the inline debug import slightly interrupts flow. Overall, the code is well organized and readable, with minor naming, repetition, and nesting issues.