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, f: App) -> None:
self.app = f
def a(
self, g: BaseEnvironment, h: str
) -> tuple[str, str | None, t.Callable[[], bool] | None]:
if self.app.config["EXPLAIN_TEMPLATE_LOADING"]:
return self.b(g, h)
return self.c(g, h)
def b(
self, i: BaseEnvironment, j: str
) -> tuple[str, str | None, t.Callable[[], bool] | None]:
k = []
l: tuple[str, str | None, t.Callable[[], bool] | None] | None
m: None | (tuple[str, str | None, t.Callable[[], bool] | None]) = None
for n, o in self.d(j):
try:
l = o.get_source(i, j)
if m is None:
m = l
except TemplateNotFound:
l = None
k.append((o, n, l))
from .debughelpers import explain_template_loading_attempts
explain_template_loading_attempts(self.app, j, k)
if m is not None:
return m
raise TemplateNotFound(j)
def c(
self, p: BaseEnvironment, q: str
) -> tuple[str, str | None, t.Callable[[], bool] | None]:
for r, s in self.d(q):
try:
return s.get_source(p, q)
except TemplateNotFound:
continue
raise TemplateNotFound(q)
def d(self, u: str) -> t.Iterator[tuple[Scaffold, BaseLoader]]:
v = self.app.jinja_loader
if v is not None:
yield self.app, v
for w in self.app.iter_blueprints():
v = w.jinja_loader
if v is not None:
yield w, v
def e(self) -> list[str]:
x = set()
y = self.app.jinja_loader
if y is not None:
x.update(y.list_templates())
for z in self.app.iter_blueprints():
y = z.jinja_loader
if y is not None:
for A in y.list_templates():
x.add(A)
return list(x)
Run 1
The code has extremely poor readability due to single-letter variable names (f, g, h, b, c, d, etc.) that obfuscate meaning and intent. Function names like 'a', 'b', 'c', 'd', 'e' and parameters like 'k', 'l', 'm', 'n', 'o' provide zero semantic context. The code lacks docstrings or comments explaining purpose. While the structure is logically organized and nesting is relatively flat, the complete absence of meaningful identifiers makes it nearly impossible to understand without extensive reverse engineering. The code length is reasonable but the action granularity is inconsistent with multiple operations occurring per line in comprehensions and updates. Reading flow suffers greatly as readers must constantly map meaningless names to their underlying concepts. Type hints provide some hints about data structures, but tuple types with nested unions are unwieldy. The code appears to be deliberately obfuscated, earning very low readability despite otherwise sound structural patterns.
Run 2
The code is severely unreadable due to meaningless variable names (f, g, h, a, b, c, d, e, etc.), which obscure the purpose of every function and parameter. The class and method names are also non-descriptive, making it impossible to infer intent without deep inspection. The logic itself is relatively simple, but the abstraction is completely lost. While the structure is somewhat linear and nesting is shallow, the lack of semantic naming defeats readability. Type hints are present, but they don't compensate for the cryptic identifiers. The single-letter loop variables and reassignment further degrade clarity. Overall, this code would require significant mental mapping for any reader, making it a poor example of maintainable code.
Run 3
This code is severely unreadable due to obfuscated naming and poor structure. Method names like 'a', 'b', 'c', 'd', and 'e' conceal their purpose, while single-letter variables (f, g, h, i, j, k, l, m, n, o, p, q, r, s, u, v, w, x, y, z, A) make it nearly impossible to understand the logic without extensive study. The code structure is tangled, with duplicated loader iteration logic in methods 'd' and 'e'. Method 'b' contains convoluted logic with unexplained state tracking (m, l, k). Reading flow is disorganized - the reader must constantly backtrack to remember what each single-letter variable represents. While each line is concise and does one action, the lack of meaningful names negates this benefit. Type hints are present but reference unclear variable names. The only clear element is the class docstring, which ironically describes a clean purpose that the implementation obscures.
Run 1
Code Structure: Responsibilities are separated into methods for dispatch, diagnostic loading, normal loading, loader iteration, and template listing. Nesting: Mostly moderate, although diagnostic loading and blueprint template collection introduce several nested levels. Clarity of intent: The class docstring and library calls provide context, but single-letter method and variable names substantially obscure purpose and relationships. Referenced App and Scaffold types are not defined or imported in the snippet, adding ambiguity. Code length: Reasonably compact, though repeated verbose tuple annotations and the nested template-collection loop add avoidable bulk. Action granularity: Statements generally perform one action per line, making individual operations easy to distinguish. Reading flow: Method ordering and straightforward control flow are sensible, but cryptic identifiers force readers to repeatedly infer meaning; the late import also slightly interrupts the diagnostic method.
Run 2
Code Structure: Responsibilities are separated into small methods for dispatching, diagnostic loading, fast loading, loader iteration, and template listing. Nesting: Mostly shallow, though diagnostic loading and template listing reach moderate nesting. Clarity of intent: The class docstring and recognizable Jinja operations help, but single-letter method and variable names severely obscure purpose and relationships. App and Scaffold annotations lack visible definitions or imports. Code length: Generally concise, although repeated complex return annotations and a nested template-listing loop add avoidable verbosity. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: Method ordering and straightforward control flow are logical, but opaque names force readers to repeatedly trace values and calls; the inline debug-helper import slightly interrupts the flow.
Run 3
Code Structure: Methods separate dispatch, diagnostic loading, normal loading, loader iteration, and template listing logically. Nesting: Mostly shallow, though diagnostic handling and template collection reach several levels. Clarity of intent: The class docstring and library calls provide context, but single-letter method and variable names severely obscure responsibilities and data roles; App and Scaffold are also not defined or imported in the snippet. Code length: Reasonably concise, although repeated complex type annotations add visual weight and the inner template-collection loop could use update(). Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Method ordering supports the loading workflow, but cryptic cross-method calls require repeated backtracking, and the local import interrupts the diagnostic method.