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 highly readable. It follows a clean, logical structure with clear separation of concerns: dispatch, explained loading, fast loading, loader iteration, and template listing. Each method has a single responsibility. Nesting is minimal, with only a couple of levels in the loops and conditionals. Intent is clear from method and variable names—e.g., `_get_source_explained` vs `_get_source_fast`, `attempts`, `trv`. Code length is appropriate and not overly verbose. Action granularity is generally one action per line, though a few multi-part lines (e.g., unpacking from `_iter_loaders`) remain clear. Reading flow is natural: the logic progresses top-down, and helper methods are well-named and ordered logically. Type hints are used sparingly but effectively. Minor room for improvement: some duplicated logic between explained and fast methods could be abstracted, and the type hint for `Scaffold` appears without import context.
Run 3
The code is well-structured and readable. It uses clear class and method names, type hints, and docstrings. The split between 'explained' and 'fast' loading paths is logical and avoids excessive nesting. Each method has a single responsibility and error handling is straightforward. Minor drawbacks include some repetitive variable type annotations and a slightly unclear 'trv' variable name, but overall intent is clear and flow is natural.
Run 1
Code Structure: Methods cleanly separate loader iteration, fast lookup, diagnostic lookup, and template listing. Nesting: Mostly shallow, although diagnostic lookup and blueprint template listing reach three levels. Clarity of intent: Descriptive method names, type hints, and the class docstring explain the purpose; abbreviated variables such as rv, trv, and srcobj obscure details. App and Scaffold types are not defined or imported in the snippet. Code length: Generally concise, but repeated complex return annotations and the template-listing loop could be simplified. Action granularity: Statements consistently perform one action per line. Reading flow: Public dispatch followed by lookup implementations and loader enumeration is logical, though the mid-method import and unused imports introduce minor distractions.
Run 2
Code Structure: Well-organized class with separate methods for loader iteration, fast lookup, diagnostic lookup, and template listing. Nesting: Mostly shallow, although diagnostic lookup and blueprint template listing introduce additional nesting. Clarity of intent: Descriptive method names, a useful class docstring, and type annotations clarify behavior; abbreviated names such as rv and trv and unexplained App and Scaffold references reduce clarity. Code length: Generally concise, but repeated complex tuple annotations and the inner template-listing loop add avoidable verbosity. Action granularity: Statements consistently perform one action per line. Reading flow: Public dispatch followed by specialized implementations reads naturally, though the local import and dense annotations slightly interrupt the flow.
Run 3
Code Structure: Well-organized class separates dispatch, diagnostic loading, fast loading, loader iteration, and template listing. Nesting: Mostly shallow, though diagnostic loading and blueprint template listing introduce several levels. Clarity of intent: Descriptive method names, a class docstring, and type annotations explain the purpose; 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 template-by-template set insertion add avoidable verbosity. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Public dispatch precedes its implementations, followed by supporting methods, producing a natural progression. The local import and unused template parameter in _iter_loaders are minor distractions.