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):
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 well-structured with clear separation of concerns and logical organization. Methods have single responsibilities and meaningful names. The nesting is minimal, with only one level of loops and conditionals in most places. Type hints enhance clarity and intent. The main readability issues are: the `_get_source_explained` method has subtle variable handling (`rv` vs `trv`) that could confuse readers, and the `_iter_loaders` method duplicates loader retrieval logic from `list_templates`. Some type annotations are verbose, adding visual noise. Overall, the code maintains good flat structure, clear action granularity, and natural reading flow, making it accessible to most Python developers.
Run 2
The code has clear separation of concerns and a logical structure, with the loader divided into explained/fast paths and helper methods for iteration. However, it suffers from readability issues: excessive blank lines disrupt flow, type aliases make signatures overly verbose, and duplicate loader-fetching logic between `_iter_loaders` and `list_templates` adds unnecessary length. Action granularity is mostly one action per line, and nesting is shallow, which is positive. The intent is clear due to well-named methods, but the `_get_source_explained` method has confusing variable names (`rv`, `trv`) and a somewhat convoluted accumulation pattern. The `EXPLAIN_TEMPLATE_LOADING` conditional adds a layer of indirection that, while documented, slightly obscures the primary execution path. Overall, the code is maintainable but could be tightened and clarified.
Run 3
The code is highly readable with clear method separation and logical structure. Each method has a single responsibility: source loading is split into 'explained' and 'fast' paths, loader iteration is isolated, and template listing is straightforward. Nesting is minimal, with at most two levels of indentation. Intent is clear from method names and type hints, though the variable names 'rv', 'trv', and 'srcobj' are slightly opaque. The code is appropriately concise without being overly compressed. Action granularity is mostly one action per line, with a few lines combining assignment and comprehension. Reading flow follows a natural top-to-bottom order: public method, then specialized implementations, then helper iteration, then template listing. The one area for improvement is the 'explained' path where the dual-tracking of 'rv' and 'trv' could be clarified.
Run 1
Code Structure: Logically organized into dispatch, diagnostic lookup, fast lookup, loader iteration, and template listing methods. Nesting: Generally shallow, though diagnostic lookup and blueprint template collection introduce moderate nesting. Clarity of intent: Descriptive method names and type annotations communicate purpose, but abbreviated variables (rv, trv, srcobj), missing contextual definitions for App and Scaffold, and absent documentation reduce clarity. Code length: Mostly concise; repeated complex tuple annotations, unused imports, and the template-by-template collection loop add avoidable verbosity. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: Public dispatch naturally leads into implementation helpers, and early returns simplify lookup logic. However, the function-local import, excessive blank space after the class declaration, and dense annotations slightly interrupt the flow.
Run 2
Code Structure: Well-organized methods separate loader iteration, fast lookup, diagnostic lookup, and template listing. Nesting: Generally shallow, although diagnostic lookup and blueprint template listing reach three levels. Clarity of intent: Descriptive method names and type annotations clarify behavior, but abbreviated variables such as rv, trv, and srcobj obscure their roles. App and Scaffold are referenced without visible imports, and several imports and the template parameter in _iter_loaders appear unused. Code length: Mostly concise, but repeated complex tuple annotations and the explicit template-adding loop add avoidable verbosity. Action granularity: Each line generally performs one clear action. Reading flow: Public dispatch followed by implementation helpers creates a natural progression; extra blank lines and the mid-method import mildly interrupt it.
Run 3
Code Structure: Methods cleanly separate dispatch, diagnostic loading, fast loading, loader iteration, and template listing. Nesting: Mostly shallow, although diagnostic loading and template listing contain modest nested control flow. Clarity of intent: Descriptive method names and type annotations clarify behavior, but abbreviated variables such as rv, trv, and srcobj obscure meaning; App and Scaffold are not defined or imported in the snippet. Code length: Generally concise, though repeated complex type annotations, unused imports, and redundant template-listing iteration add clutter. Action granularity: Statements consistently perform one action per line. Reading flow: The entry point followed by specialized implementations is natural, but the mid-method import and inconsistent whitespace slightly interrupt readability.