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 demonstrates basic organization with a clear class and method separation, but readability suffers from several issues. Method signatures are awkwardly broken across lines with inconsistent indentation and spacing, disrupting natural reading flow. The `_get_source_explained` method uses confusing variable names like `rv` and `trv` that obscure their purpose, while the redundant assignment of `rv = None` after catching `TemplateNotFound` adds unnecessary complexity. Type hints are verbose and repeated throughout, inflating code length without proportionally improving clarity. The `Scaffold` type annotation appears in the return type but is never imported, creating ambiguity. Action granularity is mixed: some methods are clean while others pack multiple conceptual steps into single lines. The decorator-free streaming context and signal imports suggest the code is incomplete, further hampering coherent understanding. Nesting is acceptable but could be flatter.
Run 2
The code has clear intent with helpful docstrings and logical organization into methods, but suffers from formatting issues. Type hints are used well, but line wrapping is inconsistent and breaks readability (e.g., 'get_source' signature). While nesting is generally flat, the explained method has unnecessary complexity with both 'rv' and 'trv' variables tracking state. Action granularity is mostly one action per line, but method definitions and type signatures exceed reasonable line lengths. Reading flow is interrupted by awkward line breaks and inconsistent spacing. The code is functional but would benefit from consistent formatting to improve readability.
Run 3
The code is generally readable with clear class and method names, logical structure, and moderate nesting. It avoids excessive depth and uses concise methods for different paths (explained vs fast). However, there are minor formatting inconsistencies in function signatures (odd line breaks and spacing), which slightly disrupt the reading flow. The action granularity is mostly one action per line, though some lines combine multiple operations. The intent is clear overall, but the `_get_source_explained` method has a slightly tangled variable naming (`rv`, `trv`) that could be more descriptive. The `_iter_loaders` method is clean, but `list_templates` duplicates loader retrieval logic, reducing conciseness. Overall, it's readable but could benefit from formatting cleanup and minor refactoring to reduce repetition and improve variable clarity.
Run 1
Code Structure: Methods logically separate loader selection, diagnostic loading, fast loading, and template listing. Nesting: Generally moderate, though diagnostic loading and blueprint template listing have several nested levels. Clarity of intent: Descriptive method names and the class docstring clarify the purpose, but abbreviations such as rv, trv, and srcobj obscure local meaning. Code length: Fairly concise, although repeated complex type annotations and the explicit template-adding loop add verbosity. Action granularity: Each line generally performs one action, making operations easy to follow. Reading flow: Control flow is natural, with straightforward fallback behavior, but inconsistent signature spacing, missing blank lines between some methods, and a mid-method import interrupt scanning. Unused imports and types not defined in the snippet add minor distractions.
Run 2
Code Structure: Responsibilities are logically separated into loader iteration, fast lookup, diagnostic lookup, and template listing. Nesting: Mostly shallow, although template listing uses three nested levels. Clarity of intent: Method names and the class docstring communicate purpose, but abbreviations such as rv, trv, and srcobj obscure meaning; App and Scaffold also lack visible imports. Code length: Reasonably concise, though repeated complex type annotations and the template-listing loop add avoidable verbosity. Action granularity: Statements generally perform one action per line. Reading flow: Control flow is natural and exceptions clearly handle missing templates, but inconsistent signature formatting, excessive internal whitespace, missing blank lines between some methods, and unused imports interrupt readability.
Run 3
Code Structure: Methods logically separate loader selection, diagnostic loading, fast loading, and template listing. Nesting: Generally moderate, though template listing reaches three nested levels. Clarity of intent: Descriptive method names and the class docstring explain the purpose, but abbreviations such as rv, trv, and srcobj obscure local meaning. Code length: Mostly concise; repeated complex type annotations and the explicit template-addition loop add avoidable verbosity. Action granularity: Each line generally performs one action, making operations easy to follow. Reading flow: Control flow is natural, but inconsistent signature spacing, long lines, and missing blank lines between some methods disrupt scanning. Unused imports and type names whose definitions are not shown also add distractions.