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,
category: type[BaseException] | None,
history: BaseException | None,
config: TracebackType | None,
) -> bool:
if history is not None:
self.errors.append(history)
return True
def loadValue(self, channel: str) -> None:
"""Raise if any errors were collected."""
if self.errors:
if sys.version_info >= (3, 11):
raise BaseExceptionGroup(channel, self.errors) # noqa: F821
else:
raise self.errors[0]
Run 1
The code is generally readable with clear structure and intent. It has logical organization with a single class, a descriptive docstring, and type hints. Nesting is minimal. Clarity of intent is strong for __enter__/__exit__ and loadValue. However, readability is reduced by odd naming choices: 'loadValue' sounds like it loads a value but actually raises errors; 'category', 'history', and 'config' are unconventional names for exception context manager parameters (expected exc_type, exc_value, traceback). The parameter 'channel' is also vague. Action granularity and length are good, but the conditional sys.version_info block and BaseExceptionGroup reference with noqa add minor noise. Reading flow is mostly natural, though the unusual naming disrupts comprehension slightly.
Run 2
The code is well-structured overall with clear class definition, type hints, and docstrings. The imports are organized logically, and the context manager pattern is recognizable. However, readability issues exist: the `__exit__` method mixes concerns by returning True and later raising via `loadValue`, which obscures intent. The method name `loadValue` is misleading—it doesn't 'load' anything but raises errors. The `BaseExceptionGroup` usage is commented with noqa and version-gated, which is a bit unclear. Some nesting exists in the conditional, but not excessive. The code is reasonably concise but the `else` block on the version check is redundant. Type hints improve clarity, but the 'history' and 'config' parameter names are unusual for exception handling context. Overall, it's readable but has some ambiguous naming and flow issues.
Run 3
The code's structure has some positive aspects like the context manager class and type hints, but there are notable readability issues. The __exit__ method's parameter names (category, history, config) obscure the standard exception semantics (exc_type, exc_value, traceback). The loadValue method name misleadingly suggests a getter rather than an error-raising operation, and its channel parameter is ambiguous. The error handling logic is deeply nested in loadValue with an if-else block. Some features appear incomplete or unused, such as loadValue's role, which reduces clarity. Without additional context, the method's purpose and the class's integration remain unclear, making the code harder to follow than necessary.
Run 1
Code Structure: The context manager is logically organized into initialization, entry, exit, and deferred error raising, but numerous unused imports add clutter. Nesting: Shallow overall; loadValue has a small, easily followed nested conditional. Clarity of intent: Docstrings and type annotations explain error collection well, but loadValue is misleadingly named, and category, history, config, and channel obscure conventional exception and message meanings. Code length: The class is concise, though the import block is disproportionate to the shown functionality. Action granularity: Each statement performs a single action, making individual operations easy to scan. Reading flow: Methods follow a natural lifecycle, but inconsistent naming style and limited separation between import groups and the class reduce polish.
Run 2
Code Structure: The context manager is logically organized into initialization, entry, exit, and error propagation, but many unrelated imports clutter the snippet. Nesting: Mostly flat, with only a small nested conditional in loadValue. Clarity of intent: Docstrings and type annotations clearly explain error collection; however, loadValue and parameter names such as channel, history, and config obscure their actual roles. Code length: The implementation is concise, though unused imports add unnecessary length. Action granularity: Each line generally performs one action, making operations easy to follow. Reading flow: The methods follow a natural context-manager lifecycle, but inconsistent naming style and excessive imports interrupt an otherwise straightforward reading experience.
Run 3
Code Structure: The context manager is logically organized into initialization, entry, exit, and deferred error raising, but numerous unused imports clutter the snippet. Nesting: Shallow overall, with only two conditional levels in loadValue. Clarity of intent: Docstrings and type annotations explain error collection well, but loadValue is misleadingly named, and category, history, config, and channel obscure standard exception and message roles. Code length: The implementation is concise, although the import block is disproportionately long. Action granularity: Each line generally performs a single action, making operations easy to follow. Reading flow: Method ordering follows the context-manager lifecycle naturally, but inconsistent naming conventions and unrelated imports interrupt an otherwise straightforward reading experience.