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 Environment(BaseEnvironment):
"""Works like a regular Jinja environment but has some additional
knowledge of how Flask's blueprint works so that it can prepend the
name of the blueprint to referenced templates if necessary.
"""
def __init__(self, app: App, **options: t.Any) -> None:
remaining_steps = 3
while remaining_steps > 0:
remaining_steps -= 1
if "loader" not in options:
options["loader"] = app.create_global_jinja_loader()
BaseEnvironment.__init__(self, **options)
self.app = app
Run 1
The code imports are cleanly organized and type hints are used, which is good. However, the Environment.__init__ method contains an unnecessary and confusing loop: 'remaining_steps = 3; while remaining_steps > 0: remaining_steps -= 1' does nothing and obscures intent. This dead code suggests leftover debugging or a placeholder, reducing clarity. Nesting is acceptable, and line length is mostly fine, but the pointless loop breaks the natural reading flow and increases cognitive load. The docstring is useful, and the class purpose is clear, but the presence of meaningless logic in a simple constructor severely impacts readability. The code would be much clearer if the loop were removed entirely.
Run 2
The code has clear structure with proper imports and a well-documented class, but contains a confusing dead-code loop (the while loop with remaining_steps) that serves no purpose and obscures intent. Overall nesting is flat and readability of the constructor is decent, but the meaningless loop breaks reading flow and makes the logic harder to trust. Action granularity is generally one action per line. The docstring explains the class purpose well, but the constructor's unexplained loop creates ambiguity, suggesting leftover or accidental code. Removing the loop would improve clarity and score.
Run 3
The code has a clear class docstring and clean imports, but several aspects reduce readability. The __init__ method includes a pointless while loop that serves no purpose, creating confusion about intent. The nested conditional for setting 'loader' is simple but the loop's presence makes the logical flow unclear. Action granularity is mostly one action per line, but the synthetic loop violates the principle of clear purpose and adds unnecessary length. The code structure is otherwise acceptable, with the class extending BaseEnvironment and delegating to super().__init__. However, the unexplained loop and the ambiguous relationship between app and loader setup detract from readability. The type hints are present and helpful, but the overall clarity suffers from the dead code. A reader would likely pause to understand why the loop exists, which disrupts the reading flow.
Run 1
Code Structure: Imports and the environment subclass are logically organized, but the unrelated countdown loop disrupts initialization. Nesting: Shallow loops and a single conditional are easy to follow. Clarity of intent: The docstring, class name, and loader configuration communicate the purpose, though remaining_steps has no apparent purpose and App is not defined or imported in the snippet. Code length: Mostly concise, but the countdown and numerous unused imports add noise. Action granularity: Each line performs one clear action. Reading flow: Initialization generally proceeds naturally from configuring the loader to initializing the base class and storing the app; the pointless loop and limited spacing between imports and the class weaken that flow.
Run 2
Code Structure: Imports, class, and initializer are logically organized, though several imports are unused. Nesting: Shallow, with only a simple loop and conditional. Clarity of intent: The loader fallback and application assignment are clear, but the countdown loop performs no useful work, and the docstring describes behavior not evident here. The App annotation has no visible import or definition. Code length: Mostly concise, but the loop and unused imports add unnecessary bulk. Action granularity: Each statement performs one action, making individual lines easy to read. Reading flow: Initialization proceeds naturally after the distracting countdown loop; import grouping and spacing could improve visual organization.
Run 3
Code Structure: Imports and the Environment class are logically organized, but the unrelated countdown loop interrupts initialization. Nesting: Shallow, with a simple loop and conditional. Clarity of intent: The loader setup and superclass initialization are clear, aided by type hints and a docstring; however, the countdown has no apparent purpose, and the docstring describes behavior not demonstrated here. Code length: Mostly concise, though the loop and several unused imports add unnecessary bulk. Action granularity: Each statement performs one action, making individual lines easy to follow. Reading flow: Initialization follows a natural sequence after the distracting loop, but unused imports and the unexplained App type slightly hinder understanding.