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 current_app:
return current_app.config["MAX_COOKIE_SIZE"] # type: ignore[no-any-return]
# return Werkzeug's default when not in an app context
return super().max_cookie_size
Run 1
The code is well-structured with clear imports, a single class with a clear docstring, and minimal nesting. Intent is apparent through descriptive names and type hints. The class docstring is thorough but slightly verbose for this snippet length. The max_cookie_size property is flat and readable, with a clear fallback path. Action granularity is one action per line. Reading flow is natural, though the lengthy docstring interrupts the flow slightly. Overall, highly readable with only minor verbosity in documentation.
Run 2
The code is highly readable with clear structure and intent. It uses standard imports, type hints, and a well-documented class. The Response class is logically organized with attributes and a property method. Nesting is minimal (one conditional), actions are granular and line-by-line, and the reading flow is natural. The docstring is thorough but slightly verbose, slightly reducing conciseness. Overall, this is clean, maintainable Flask code.
Run 3
The code is well-structured with clear class-based organization and logical imports. It maintains a shallow nesting depth with only one conditional, and its intent is explicit through descriptive class/method names, type hints, and a comprehensive docstring. The code is concise—each line or small block performs a single action, avoiding verbosity. Reading flow is natural, progressing from imports to class definition to property accessor. The `max_cookie_size` property is particularly clear: it checks for an app context, returns the configured value, or falls back to Werkzeug's default. Minor deductions are for the inline `# type: ignore` comments, which slightly disrupt readability, and the docstring's version notes are somewhat verbose. Overall, this code demonstrates high readability.
Run 1
Code Structure: Imports, class configuration, and the property method are logically organized, though additional spacing between sections would help. Nesting: Only one shallow conditional keeps the code easy to follow. Clarity of intent: Descriptive names, type annotations, documentation, and the fallback comment clearly explain the response customization and configuration lookup. Code length: The implementation is concise; the lengthy class docstring and repeated version-change headings add minor reading overhead. Action granularity: Each statement performs a single action, with no compressed operations. Reading flow: The property naturally proceeds from application configuration to the superclass default. Framework-specific references and type-ignore comments slightly interrupt an otherwise clear flow.
Run 2
Code Structure: Imports, class documentation, defaults, and the property are logically organized, though unused imports add clutter. Nesting: A single conditional keeps the implementation flat and easy to follow. Clarity of intent: Descriptive names, type annotations, and documentation clearly explain the response defaults and configuration lookup. Code length: The implementation is concise; the lengthy docstring and repeated version-change headings slightly outweigh the code's simplicity. Action granularity: Each executable line performs one clear action. Reading flow: The property naturally proceeds from checking the application context to returning the configured value or inherited default. Missing blank lines around the import groups and class declaration slightly reduce visual separation.
Run 3
Code Structure: Imports, class documentation, defaults, and the property are logically organized, though several imports are unused in this snippet. Nesting: A single conditional keeps the implementation shallow and easy to follow. Clarity of intent: Descriptive names, type annotations, and documentation clearly explain the response defaults and configuration-based cookie-size limit. Code length: The implementation is concise, although the class docstring is lengthy relative to the executable code and repeats a version-change heading. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: The code proceeds naturally from class configuration to property behavior, and the fallback comment clarifies the final return. Minor spacing inconsistencies and type-ignore annotations add a little visual noise.