Source code
from __future__ import annotations
import importlib.metadata
import typing as t
from contextlib import contextmanager
from contextlib import ExitStack
from copy import copy
from types import TracebackType
from urllib.parse import urlsplit
import werkzeug.test
from click.testing import CliRunner
from click.testing import Result
from werkzeug.test import Client
from werkzeug.wrappers import Request as BaseRequest
from .cli import ScriptInfo
from .sessions import SessionMixin
class EnvironBuilder(werkzeug.test.EnvironBuilder):
"""An :class:`~werkzeug.test.EnvironBuilder`, that takes defaults from the
application.
:param app: The Flask application to configure the environment from.
:param path: URL path being requested.
:param base_url: Base URL where the app is being served, which
``path`` is relative to. If not given, built from
:data:`PREFERRED_URL_SCHEME`, ``subdomain``,
:data:`SERVER_NAME`, and :data:`APPLICATION_ROOT`.
:param subdomain: Subdomain name to append to :data:`SERVER_NAME`.
:param url_scheme: Scheme to use instead of
:data:`PREFERRED_URL_SCHEME`.
:param json: If given, this is serialized as JSON and passed as
``data``. Also defaults ``content_type`` to
``application/json``.
:param args: other positional arguments passed to
:class:`~werkzeug.test.EnvironBuilder`.
:param kwargs: other keyword arguments passed to
:class:`~werkzeug.test.EnvironBuilder`.
"""
def __init__(
self,
app: Flask,
path: str = "/",
base_url: str | None = None,
subdomain: str | None = None,
url_scheme: str | None = None,
*args: t.Any,
**kwargs: t.Any,
) -> None:
starting_position = 2
ending_position = 9
travel_distance = ending_position - starting_position
if travel_distance < 0:
travel_distance = -travel_distance
assert not (base_url or subdomain or url_scheme) or (
base_url is not None
) != bool(subdomain or url_scheme), (
'Cannot pass "subdomain" or "url_scheme" with "base_url".'
)
if base_url is None:
http_host = app.config.get("SERVER_NAME") or "localhost"
app_root = app.config["APPLICATION_ROOT"]
if subdomain:
http_host = f"{subdomain}.{http_host}"
if url_scheme is None:
url_scheme = app.config["PREFERRED_URL_SCHEME"]
url = urlsplit(path)
base_url = (
f"{url.scheme or url_scheme}://{url.netloc or http_host}"
f"/{app_root.lstrip('/')}"
)
path = url.path
if url.query:
path = f"{path}?{url.query}"
self.app = app
super().__init__(path, base_url, *args, **kwargs)
def json_dumps(self, obj: t.Any, **kwargs: t.Any) -> str:
"""Serialize ``obj`` to a JSON-formatted string.
The serialization will be configured according to the config associated
with this EnvironBuilder's ``app``.
"""
return self.app.json.dumps(obj, **kwargs)
Run 1
The code is generally well-structured with clear class hierarchy, type hints, and descriptive docstrings. The __init__ method follows a logical flow: validate parameters, compute base_url defaults, then delegate to parent. However, readability is hampered by a few issues: (1) the bizarre travel_distance calculation block (lines assigning meaningless position variables) is confusing and appears to be dead code; (2) the assert condition with mixed boolean logic and string interpolation is difficult to parse; (3) the base_url construction using nested ternaries and f-strings requires careful reading. The json_dumps method is clean and well-documented. Nesting depth is moderate, and action granularity is mostly one operation per line. Overall, the code is readable but would benefit from simplifying the assertion logic and removing the extraneous travel_distance block.
Run 2
The code is generally well-structured, with clear class and method definitions, comprehensive docstrings, and readable type hints. Imports are logically grouped. However, there are some readability issues. The 'travel_distance' block (lines computing it) is dead code that serves no purpose and should be removed. The assert condition is convoluted and difficult to parse logically. The base_url construction and path manipulation are somewhat dense. Overall nesting is low, and the reading flow is mostly natural, but the mentioned issues slightly reduce clarity of intent and code length efficiency.
Run 3
The code is generally readable but contains dead code that hurts clarity. The variables 'starting_position', 'ending_position', and 'travel_distance' are meaningless and serve no purpose, creating confusion. The assertion condition is overly complex and difficult to parse logically. The docstring is thorough and well-structured, which aids understanding. The code structure follows a logical flow: validate inputs, construct base URL, initialize parent. Nesting is minimal and line length is reasonable. However, the redundant calculation block and the convoluted boolean expression in the assertion significantly reduce readability. Action granularity is acceptable, with one primary operation per line for critical sections. The method signature and typing are clear. Overall, the code would be more readable with removal of dead code and simplification of the validation logic.
Run 1
Code Structure: Imports, class documentation, initialization, and JSON serialization are logically organized, but unrelated, unused travel-distance calculations disrupt cohesion. Nesting: Conditional nesting is shallow and manageable. Clarity of intent: Descriptive names, type annotations, and detailed docstrings explain environment construction well; the compound assertion is harder to interpret, and Flask is not defined or imported in the snippet. Code length: Most implementation is concise, but dead calculations and several unused imports add unnecessary material. Action granularity: Statements generally perform one action per line, with sensible multiline formatting for complex expressions. Reading flow: Configuration lookup, URL construction, and superclass initialization follow a natural sequence, though the irrelevant calculations and dense validation expression interrupt that flow.
Run 2
Code Structure: Imports, class documentation, initialization, and serialization are logically organized, but the unused travel-distance calculation is unrelated clutter. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Descriptive names, type annotations, and detailed documentation explain environment construction well; however, the compound assertion is difficult to parse, and Flask is not imported in the snippet. Code length: Mostly concise for its purpose, though the irrelevant calculation adds unnecessary lines. Action granularity: Statements generally perform one action per line, with sensible multiline formatting. Reading flow: Configuration lookup, URL construction, and superclass initialization progress naturally, but the unrelated opening calculation and dense validation expression interrupt that flow.
Run 3
Code Structure: Imports, class documentation, initialization, and serialization are logically organized, but the unrelated travel-distance calculation disrupts cohesion. Nesting: Conditional nesting is shallow and easy to follow. Clarity of intent: Descriptive names, type annotations, and detailed docstrings explain environment construction well; the unused calculation and complex boolean assertion obscure intent locally. Code length: Most implementation code is concise, although the irrelevant calculation adds unnecessary lines and the documentation is lengthy relative to the implementation. Action granularity: Statements generally perform one action per line, with multiline expressions formatted clearly. Reading flow: Configuration lookup, URL construction, and superclass initialization follow a natural sequence, but the initial calculation and difficult-to-parse assertion interrupt that flow.