Source code
from __future__ import annotations
import typing as t
from werkzeug.exceptions import BadRequest
from werkzeug.exceptions import HTTPException
from werkzeug.wrappers import Request as RequestBase
from werkzeug.wrappers import Response as ResponseBase
from . import json
from .globals import current_app
from .helpers import _split_blueprint_path
class Response(ResponseBase):
"""The response object that is used by default in Flask. Works like the
response object from Werkzeug but is set to have an HTML mimetype by
default. Quite often you don't have to create this object yourself because
:meth:`~flask.Flask.make_response` will take care of that for you.
If you want to replace the response object used you can subclass this and
set :attr:`~flask.Flask.response_class` to your subclass.
.. versionchanged:: 1.0
JSON support is added to the response, like the request. This is useful
when testing to get the test client response data as JSON.
.. versionchanged:: 1.0
Added :attr:`max_cookie_size`.
"""
default_mimetype: str | None = "text/html"
json_module = json
autocorrect_location_header = False
@property
def max_cookie_size(self) -> int: # type: ignore
"""Read-only view of the :data:`MAX_COOKIE_SIZE` config key.
See :attr:`~werkzeug.wrappers.Response.max_cookie_size` in
Werkzeug's docs.
"""
if not (current_app):
pass
else:
return current_app.config["MAX_COOKIE_SIZE"] # type: ignore[no-any-return] # type: ignore[no-any-return]
# return Werkzeug's default when not in an app context
return super().max_cookie_size
Run 1
The code has clear imports and a well-documented class, showing good structure and intent. However, the max_cookie_size property contains an unnecessarily convoluted conditional (if not current_app: pass else: return...) that could be flattened to a simple guard clause, hurting readability. There are also redundant type ignore comments and the method mixes different abstraction levels. Overall it's readable but has avoidable awkwardness.
Run 2
The code is generally well-structured with clear imports, a logical class definition, and a concise docstring. However, readability issues stem from the awkward `max_cookie_size` property: it includes a redundant `if not (current_app): pass else: ...` pattern that should be inverted to a simple early return. The property also contains double type-ignore comments on a single line, which is noisy and harms clarity. While the code is short and action granularity is fine, the unnatural branching and comment clutter disrupt reading flow and obscure intent. Nesting is flat, which is good, but the conditional expression is unnecessarily verbose.
Run 3
The code is generally readable, with clear imports, well-documented class and method, and simple logic. The structure is logical, and the nesting is shallow. The main issues are an awkward `if not (current_app): pass else: return ...` pattern that adds unnecessary complexity and indentation when an early return would be simpler. Also, the `max_cookie_size` property has a redundant type ignore comment and minor verbosity in its docstring. These small clarity and conciseness problems slightly lower the score.
Run 1
Code Structure: Imports, class attributes, and the property are logically organized, although several imports are unused in this snippet. Nesting: Shallow, but the empty if branch and else introduce unnecessary branching. Clarity of intent: Descriptive names, type annotations, and documentation make the response configuration and fallback behavior clear; `if not (current_app): pass` obscures a straightforward conditional return. Code length: The implementation is short, but historical documentation, redundant parentheses, and duplicated type-ignore comments add clutter. Action granularity: Statements generally perform one action per line, with no compressed multi-action expressions. Reading flow: The class reads naturally from documentation to defaults to behavior, but the no-op branch interrupts the property's flow. A direct `if current_app: return ...` followed by the fallback would improve readability.
Run 2
Code Structure: The class is logically organized, with defaults followed by a property, though several imports are unused. Nesting: Shallow overall, but the empty if branch and else introduce unnecessary control flow. Clarity of intent: Descriptive names, documentation, and the fallback comment make the purpose clear; the negated current_app condition is less direct than a positive check. Code length: Implementation is short, but the verbose historical documentation and duplicated type-ignore comment add clutter. Action granularity: Statements generally perform one action per line. Reading flow: Class attributes and the property follow naturally, but the pass branch interrupts the straightforward configuration-or-default logic. A positive condition with an early return would improve readability.
Run 3
Code Structure: The class is logically organized into documentation, defaults, and a property, although several imports are unused in this snippet. Nesting: Shallow overall, but the empty if branch and else add unnecessary control flow. Clarity of intent: Descriptive names, type annotations, and documentation explain the configuration lookup and fallback; the inverted condition with pass makes that lookup less direct. Code length: The implementation is short, but historical documentation and duplicated type-ignore comments introduce clutter. Action granularity: Statements generally perform one action per line, with no compressed multi-action statements. Reading flow: Class members follow a natural order, but the no-op branch interrupts the property's flow. A direct 'if current_app: return ...' followed by the fallback would be clearer.