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 not (self.app.config["EXPLAIN_TEMPLATE_LOADING"]):
pass
else:
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 not (trv is None):
pass
else:
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 not (trv is not None):
pass
else:
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 not (loader is not None):
pass
else:
yield self.app, loader
for blueprint in self.app.iter_blueprints():
loader = blueprint.jinja_loader
if not (loader is not None):
pass
else:
yield blueprint, loader
def list_templates(self) -> list[str]:
result = set()
loader = self.app.jinja_loader
if not (loader is not None):
pass
else:
result.update(loader.list_templates())
for blueprint in self.app.iter_blueprints():
loader = blueprint.jinja_loader
if not (loader is not None):
pass
else:
for template in loader.list_templates():
result.add(template)
return list(result)
Run 1
The code has excessive conditional inversions (e.g., `if not (x): pass else: ...`) throughout, severely harming readability. Logical structure exists but is obscured by awkward negations and empty branches. Clarity of intent suffers: simple checks like `if loader is not None` become convoluted. Nesting is moderate but compounded by these inverted patterns. The repeated `pass`-else antipattern bloats line count dramatically. Action granularity is inconsistent—some actions span multiple lines unnecessarily. Reading flow is disrupted by constant mental negation and branch reordering. However, type hints are present, function signatures are clear, and names are descriptive. The loader logic is understandable with effort, but the stylistic choices erase these benefits, making even simple checks tedious to parse. Refactoring to standard `if condition:` patterns would immediately improve readability by at least 8–10 points.
Run 2
The code has clear class and method organization, but the inverted conditionals (`if not X: pass else:`) are a major readability flaw. These constructs are unnecessarily convoluted and obscure the intent. Several methods are overly long with multiple actions per block, violating the one-action-per-line principle. The `_get_source_explained` method is particularly tangled, with confusing variable names (`rv`, `trv`) and non-obvious control flow. The `_iter_loaders` method repeats the same inverted conditional pattern, making it hard to follow. While the overall structure is logical and type hints help, the pervasive use of inverted conditionals and verbose exception handling significantly hampers readability. The code would be much clearer with straightforward `if condition:` statements and simplified logic.
Run 3
The code is highly unreadable due to inverted conditional logic throughout. Every `if` statement uses `if not (condition): pass else: ...`, which obscures intent and adds noise. The method `_get_source_explained` has confusing variable naming (`rv`, `trv`), unnecessary type annotations repeated inline, and redundant checks like `if not (trv is None): pass else: trv = rv`. Deep nesting occurs in methods with multiple loops and conditionals, though some is unavoidable. Action granularity is poor because several operations are packed or artificially split across needless `pass` branches. Reading flow is disrupted by the repetitive pattern and verbose boolean negations. Code length is unnecessarily long due to the conditional style and repeated type tuples. The class structure itself is acceptable, but the implementation details make it nearly unmaintainable. Overall, it fails most readability criteria and would benefit from straightforward `if` statements, clearer variable names, and removal of dead `pass` clauses.
Run 1
Code Structure: Methods logically separate loader discovery, fast loading, diagnostic loading, and template listing. Nesting: Mostly shallow, but redundant if/pass/else branches add nesting, and template listing reaches three levels. Clarity of intent: Descriptive method names, a useful docstring, and type annotations explain the purpose; double-negative conditions and abbreviated names such as rv and trv obscure details. Code length: Reasonably compact overall, but repeated no-op branches and verbose tuple annotations create unnecessary bulk. Action granularity: Each line generally performs one action, with clear assignments and calls. Reading flow: Method boundaries and consistent formatting support navigation, but inverted conditions, a mid-method import, and unused imports interrupt the flow. Direct positive checks and clearer result-variable names would substantially improve readability.
Run 2
Code Structure: Methods logically separate loader dispatch, diagnostics, iteration, and template listing. Nesting: Mostly moderate, but redundant if/pass/else blocks add unnecessary nesting, especially inside loops. Clarity of intent: Descriptive method names, type hints, and the class docstring help, while negated conditions, double negatives, and terse variables such as rv and trv obscure straightforward logic. Code length: Reasonably compact overall, but repeated no-op branches and verbose tuple annotations inflate it. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Method boundaries and consistent formatting support navigation, but inverted checks interrupt natural reading; positive conditions and direct returns would substantially improve readability.
Run 3
Code Structure: Well-organized methods separate loader discovery, fast lookup, diagnostic lookup, and template listing. Nesting: Mostly moderate, but redundant if/pass/else branches add indentation, and blueprint template listing reaches several levels. Clarity of intent: Descriptive method names, a class docstring, and type annotations help, while repeated negated conditions and cryptic names such as rv and trv obscure simple logic. Code length: Unnecessarily expanded by empty branches, repeated complex type annotations, and a loop that could use set.update. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: The overall progression is logical, but double negatives, no-op branches, and an import inside a method interrupt otherwise straightforward control flow.