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,
exc: type[BaseException] | None,
exc2: BaseException | None,
exc3: TracebackType | None,
) -> bool:
if exc2 is not None:
self.errors.append(exc2)
return True
def raise2(self, mes: str) -> None:
"""Raise if any errors were collected."""
if self.errors:
if sys.version_info >= (3, 11):
raise BaseExceptionGroup(mes, self.errors) # noqa: F821
else:
raise self.errors[0]
Run 1
The code is highly readable with clear structure and intent. The class has a single responsibility (collecting and re-raising errors), each method is concise with one action per line, and docstrings explain the 'why' behind the design. Naming is descriptive (_CollectErrors, raise2, errors). Type hints are used consistently. Minor deductions: `raise2` method name could be more explicit (e.g., `maybe_raise`), and the `__enter__` method's `pass` is slightly noisy but acceptable. The version-specific conditional for BaseExceptionGroup adds mild cognitive load but is well-contained. Overall, it reads naturally from top to bottom with excellent organization.
Run 2
The code is highly readable. It has a clear, single-purpose class with a concise docstring explaining its intent. Structure is logical: the class handles error collection and raising, with methods separated appropriately. Nesting is minimal—only three levels in `raise2` (if, nested if/else), and the `__exit__` method is flat. Each action is on its own line, improving clarity. Imports and type hints are well-organized, aiding intent. The only slight deduction is the use of slightly opaque parameter names (`exc`, `exc2`, `exc3`) and the inline `# noqa: F821` comment, which slightly interrupts reading flow. Overall, it is concise, well-structured, and easy to understand.
Run 3
The code is generally well-structured and readable. It has clear class and method organization, minimal nesting, and good type hints. The purpose of the context manager is well-documented with a docstring. Most lines perform one action, and the reading flow is natural. Minor deductions: the parameter names (exc, exc2, exc3) are cryptic and could be more descriptive; the conditional version check with a noqa comment adds slight complexity; and the `raise2` method name is unclear without reading its docstring. The code is concise and avoids unnecessary verbosity, making it easy to follow overall.
Run 1
Code Structure: The context manager is logically organized, with initialization, entry, exit, and deferred error handling clearly separated. Nesting: Mostly flat, with only two levels of conditional nesting in raise2. Clarity of intent: The class docstring and type annotations explain its purpose, but raise2, mes, and exc2/exc3 are vague names that obscure meaning. Code length: The implementation is concise, although many imports are unused in this snippet and add visual clutter. Action granularity: Statements generally perform one action per line, making execution easy to follow. Reading flow: Methods follow the context-manager lifecycle naturally, ending with error reporting; however, the long import block and unconventional parameter and method names slightly interrupt readability.
Run 2
Code Structure: The class is logically organized into initialization, context-manager methods, and error reporting, although many unrelated imports distract from the small implementation. Nesting: Control flow is shallow, with only two levels in raise2. Clarity of intent: Docstrings and type annotations explain error collection and suppression well, but raise2, mes, and exc2 are vague names; conventional exception parameter names would help. Code length: The implementation is concise, though the import block is disproportionately long for the shown functionality. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Methods follow a natural lifecycle, but minimal separation around imports and the class, plus cryptic naming, slightly interrupt readability.
Run 3
Code Structure: The context manager is logically organized into initialization, entry, exit, and error reporting, though many unrelated imports clutter the snippet. Nesting: Control flow is shallow, with only two levels in error reporting. Clarity of intent: The class docstring, method docstring, and type annotations explain its purpose well, but names such as raise2, mes, and exc2 are vague and nonstandard. Code length: The implementation is concise, although the import section is disproportionately long for the functionality shown. Action granularity: Each line generally performs one action, making operations easy to distinguish. Reading flow: Methods follow the context-manager lifecycle naturally, followed by deferred error reporting; minimal spacing between imports and the class and ambiguous parameter names slightly interrupt that flow.