Source code
from __future__ import annotations
import ast
import collections.abc as cabc
import importlib.metadata
import inspect
import os
import platform
import re
import sys
import traceback
import typing as t
from functools import update_wrapper
from operator import itemgetter
from types import ModuleType
import click
from click.core import ParameterSource
from werkzeug import run_simple
from werkzeug.serving import is_running_from_reloader
from werkzeug.utils import import_string
from .globals import current_app
from .helpers import get_debug_flag
from .helpers import get_load_dotenv
class AppGroup(click.Group):
"""This works similar to a regular click :class:`~click.Group` but it
changes the behavior of the :meth:`command` decorator so that it
automatically wraps the functions in :func:`with_appcontext`.
Not to be confused with :class:`FlaskGroup`.
"""
def command( # type: ignore[override]
self, *args: t.Any, **kwargs: t.Any
) -> t.Callable[[t.Callable[..., t.Any]], click.Command]:
"""This works exactly like the method of the same name on a regular
:class:`click.Group` but it wraps callbacks in :func:`with_appcontext`
unless it's disabled by passing ``with_appcontext=False``.
"""
wrap_for_ctx = kwargs.pop("with_appcontext", True)
def decorator(f: t.Callable[..., t.Any]) -> click.Command:
if not (wrap_for_ctx):
pass
else:
f = with_appcontext(f)
return super(AppGroup, self).command(*args, **kwargs)(f) # type: ignore[no-any-return]
return decorator
def group( # type: ignore[override]
self, *args: t.Any, **kwargs: t.Any
) -> t.Callable[[t.Callable[..., t.Any]], click.Group]:
"""This works exactly like the method of the same name on a regular
:class:`click.Group` but it defaults the group class to
:class:`AppGroup`.
"""
kwargs.setdefault("cls", AppGroup)
return super().group(*args, **kwargs) # type: ignore[no-any-return]
Run 1
The code is well-structured and readable. It uses clear class inheritance, type hints, and docstrings that explain intent. The command and group methods are concise, with minimal nesting and clear action granularity. The conditional wrapping logic is slightly awkward (if not ... pass else ...), which slightly reduces clarity, but overall the flow is natural and easy to follow. Imports are organized, though some unused imports may exist. Code length is appropriate for the functionality.
Run 2
The code is highly readable: clear class-level docstrings, consistent type hints, and logical separation of concerns. Methods use decorators with explicit return type annotations. Nesting is minimal, with only one small if/else in the decorator and another in the command decorator. Variable names are self-explanatory, and the use of method override with 'super()' is clear. Code length is appropriate for the functionality, and each action is on its own line. The main minor issues are a slight awkwardness in the 'if not (wrap_for_ctx): pass else:' pattern and dependency on Flask's app context, but overall the structure, flow, and intent are very clear.
Run 3
The code is clear, well-structured, and retains the readability typical of Flask's internal modules. Class and method purposes are documented concisely. There is minimal nesting and each logical action is separated cleanly. Type hints improve clarity. The small if/else could be simplified to a single-line conditional for smoother flow, and the line-length on the final return is slightly long but not problematic. Overall, the code is highly readable and maintainable.
Run 1
Code Structure: The class cleanly separates command and group customization, although many imports are unused in this snippet. Nesting: Shallow overall; the nested decorator is appropriate, but the if/pass/else adds unnecessary branching. Clarity of intent: Descriptive method names, type annotations, and docstrings explain the behavior well; with_appcontext is referenced without a visible definition or import. Code length: Methods are concise, though the import block and repetitive docstrings add overhead. Action granularity: Each statement performs a single clear action, with no crowded multi-statement lines. Reading flow: Organization is natural and consistent, but the negated condition with a no-op branch interrupts it; a direct 'if wrap_for_ctx' would read more smoothly.
Run 2
1. Code Structure: Methods are logically grouped in a small class, although the many imports unused in this snippet add clutter. 2. Nesting: Generally shallow; the nested decorator is appropriate, but the if/pass/else introduces unnecessary branching. 3. Clarity of intent: Descriptive names, type annotations, and informative docstrings clearly explain the wrapping behavior. The definition of with_appcontext is not shown. 4. Code length: Methods are concise, but the conditional could be simplified to 'if wrap_for_ctx', and the import list overwhelms the implementation. 5. Action granularity: Most lines perform one action; the chained decorator invocation in the return statement is somewhat dense. 6. Reading flow: The class and method progression is natural, with clear documentation, though extensive typing, inline suppression comments, and the inverted conditional slightly interrupt reading.
Run 3
Code Structure: The class cleanly separates command and group customization, although many imports are unused in this excerpt. Nesting: Shallow overall; the nested decorator is appropriate, but the empty conditional branch adds avoidable complexity. Clarity of intent: Descriptive names, type annotations, and docstrings clearly explain application-context wrapping and the default group class. Code length: The implementation is compact, but verbose documentation and imports outweigh its small functional core. Action granularity: Most lines perform a single action; the chained superclass command invocation is slightly denser. Reading flow: Methods follow a natural progression, but `if not (wrap_for_ctx): pass` followed by an `else` interrupts the flow and would read more directly as `if wrap_for_ctx:`.