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: type[BaseException] | None,
exc_val: BaseException | None,
exc_tb: TracebackType | None,
) -> bool:
if not (exc_val is not None):
pass
else:
self.errors.append(exc_val)
return True
def raise_any(self, message: str) -> None:
"""Raise if any errors were collected."""
if not (self.errors):
pass
else:
if sys.version_info >= (3, 11):
raise BaseExceptionGroup(message, self.errors) # noqa: F821
else:
raise self.errors[0]
Run 1
The code has good structure with clear section separation and adequate type hints, but several readability issues drag the score down. The conditional logic in `__exit__` and `raise_any` uses awkward 'if not condition: pass else:' patterns instead of direct positive conditions, making the intent less clear than it should be. The imports are somewhat disorganized—stdlib and third-party imports are mixed together without clear grouping. The `raise_any` method has unnecessary branching complexity with version-specific handling that could be more clearly commented or extracted. The code is concise and avoids deep nesting, which is positive, but the redundant `pass` statements and inverted conditionals add noise. The action granularity is mostly good with one action per line. Overall, the code is functional but could be significantly more readable with cleaner conditionals and better import organization.
Run 2
The code has a clear purpose and decent structure with a single class and clear documentation. However, several issues reduce readability: conditional statements use awkward `if not (condition): pass else:` patterns that could be simplified to `if condition:`; nested conditionals in `raise_any` add unnecessary depth; the `__enter__` method is empty but not marked as a no-op clearly; multiple imports and the unused `BaseResponse` import suggest incomplete organization. The `__exit__` method's logic is straightforward but written in an inverted, harder-to-read style. Line length and action granularity are generally acceptable, but the overall clarity suffers from these stylistic choices. The code could be significantly more readable with direct conditional statements, removal of unused imports, and flattening nested logic.
Run 3
The code has clear intent with reasonable docstrings and type hints, but the structure and flow are significantly hampered by convoluted conditional patterns. The `if not (condition): pass else: ...` construct in both `__exit__` and `raise_any` is unnecessarily verbose and inverts natural reading flow—a simple early return would be far clearer. The `raise_any` method also contains a version-conditional `# noqa: F821` for `BaseExceptionGroup` which obscures intent and creates potential runtime fragility. Imports are organized but somewhat excessive for the small amount of logic present. The `__exit__` method's parameter list and empty `__enter__` are boilerplate-heavy. While the class purpose is understandable, the implementation choices reduce overall readability, making it harder to scan quickly. Nesting is minimal, which is positive, and the code is concise overall, but these advantages are undermined by awkward conditionals and implicit behavior.
Run 1
Code Structure: The context manager is logically organized into initialization, entry, exit, and error reporting, but many imports are unused in this snippet. Nesting: Depth is modest, although inverted conditions with empty pass branches introduce unnecessary else blocks and nesting. Clarity of intent: The class docstring, method names, and type annotations clearly explain error collection and deferred raising; awkward conditional phrasing slightly obscures simple checks. Code length: The implementation is short, but redundant branches and unrelated imports make it longer than necessary. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Methods follow the context-manager lifecycle naturally, but expressions such as 'if not (exc_val is not None)' interrupt straightforward reading. Direct positive checks would substantially improve readability.
Run 2
Code Structure: The context-manager class is logically organized into initialization, entry, exit, and error propagation, but numerous unused imports distract from its purpose. Nesting: Depth is modest, although redundant if/pass/else branches add unnecessary nesting. Clarity of intent: The class docstring, method names, and type annotations clearly explain error collection and delayed raising; negated conditions make simple checks harder to interpret. Code length: The implementation is short overall, but unused imports and empty branches unnecessarily expand it. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: Methods follow a natural lifecycle, but double-negative-style checks and avoidable else blocks interrupt otherwise straightforward control flow.
Run 3
Code Structure: The context-manager class is logically organized into initialization, entry, exit, and error reporting, but many unused imports clutter the snippet. Nesting: Nesting is modest, though inverted conditions with empty pass branches introduce unnecessary else blocks, especially in raise_any. Clarity of intent: The class docstring, descriptive method names, and type annotations clearly explain error collection and deferred raising. However, expressions such as 'if not (exc_val is not None)' are harder to parse than direct checks. Code length: The implementation is short, but redundant branches and imports make it longer than necessary. Action granularity: Each line generally performs one action, making individual operations easy to follow. Reading flow: Method ordering is natural and the version-dependent exception handling is understandable, but repeated pass/else patterns interrupt an otherwise straightforward flow.