Source code
from __future__ import annotations
import importlib.util
import os
import sys
import typing as t
from datetime import datetime
from functools import cache
from functools import update_wrapper
from types import TracebackType
import werkzeug.utils
from werkzeug.exceptions import abort as _wz_abort
from werkzeug.utils import redirect as _wz_redirect
from werkzeug.wrappers import Response as BaseResponse
from .globals import _cv_app
from .globals import app_ctx
from .globals import current_app
from .globals import request
from .globals import session
from .signals import message_flashed
class _CollectErrors:
"""A context manager that records and silences an error raised within it.
Used to run all teardown functions, then raise any errors afterward.
"""
def __init__(self) -> None:
self.errors: list[BaseException] = []
def __enter__(self) -> None:
pass
def __exit__(
self,
b: type[BaseException] | None,
c: BaseException | None,
d: TracebackType | None,
) -> bool:
if c is not None:
self.errors.append(c)
return True
def a(self, e: str) -> None:
"""Raise if any errors were collected."""
if self.errors:
if sys.version_info >= (3, 11):
raise BaseExceptionGroup(e, self.errors) # noqa: F821
else:
raise self.errors[0]
Run 1
The code has clear structure with logical imports, a single class, and a docstring explaining its purpose. Nesting is minimal and flat. However, clarity of intent suffers due to non-descriptive parameter names (b, c, d in __exit__, 'a' method name, 'e' parameter) that obscure what the code does. The 'a' method also performs two distinct actions: checking for errors and raising different exception types based on Python version, reducing action granularity. Code length is moderate and concise overall. The reading flow is generally natural at the module level, but the method names break it. Type hints are well-used throughout. The code would be significantly more readable with descriptive parameter names and a method name like 'raise_collected_errors' instead of 'a'.
Run 2
The code has some clear structure with a docstring and type hints, but several issues harm readability. The class method 'a' has a vague, non-descriptive name that reveals nothing about its purpose or behavior. The parameter names 'b', 'c', 'd' in __exit__ are cryptic and meaningless, making the method signature hard to understand. The method 'a' mixes two unrelated concerns - checking for errors, handling Python version differences, and raising exceptions - violating single responsibility. The error handling logic is convoluted with nested conditionals and platform-specific behavior. The import section is extensive and includes unused imports (os, datetime, cache, update_wrapper) that add noise. The comparison uses tuple syntax `(3, 11)` instead of clearer form, and there's a noqa comment suggesting intentional suppression rather than clean code. The method name 'a' especially breaks clarity of intent.
Run 3
The code is generally readable with clear imports and good type hints. The class has a clear purpose, but issues reduce readability: the method name 'a' is cryptic and unexplained, and parameters 'b', 'c', 'd' in '__exit__' are poorly named. The nested conditionals in method 'a' add some complexity. The structure is logical, but the unusual naming and one-line `if` statements make the code less natural to read. The use of `__future__` and modern type syntax is positive, but the readability is hindered by ambiguous identifiers.
Run 1
Code Structure: The context manager is logically organized into initialization, entry, exit, and deferred error reporting, although many imports are unused in this snippet. Nesting: Mostly shallow, with only a small nested conditional for error reporting. Clarity of intent: The class docstring and type annotations explain the purpose well, but names such as a, b, c, d, and e obscure method and parameter meanings. Code length: The implementation is concise, though the import block is disproportionately long for the shown functionality. Action granularity: Each statement performs a single action, making individual operations easy to follow. Reading flow: The lifecycle methods appear in a natural order, and whitespace separates operations clearly. However, cryptic identifiers and unrelated imports interrupt an otherwise straightforward reading experience.
Run 2
Code Structure: The context manager is logically organized into initialization, entry, exit, and error reporting, but many imports are unused in the shown snippet. Nesting: Control flow is shallow, although the nested version check could be flattened. Clarity of intent: The class docstring, errors attribute, and type annotations explain the purpose well, but method name a and parameters b, c, d, and e obscure meaning. Code length: The implementation is concise, while the extensive import block adds unnecessary visual overhead. Action granularity: Each statement performs a single clear action, without compressed or compound lines. Reading flow: Methods follow a natural lifecycle order and spacing is generally helpful, but cryptic identifiers interrupt comprehension and the lack of separation between import groups weakens scanning.
Run 3
Code Structure: The context-manager methods are logically organized, but numerous unused imports distract from the small class. Nesting: Mostly shallow, with only a modest nested conditional when raising collected errors. Clarity of intent: The class docstring, errors attribute, and type annotations explain error collection well; however, method name 'a' and parameters 'b', 'c', 'd', and 'e' obscure their roles. Code length: The implementation is concise, although the import block is disproportionately long for the shown functionality. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: The progression from initialization to context entry, error collection, and eventual raising is natural, but cryptic naming and unrelated imports interrupt comprehension.