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 a(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 and readable. It uses clear imports, descriptive class names, and a docstring explaining the purpose. The nesting level is minimal, and variable/method names are clear. However, the property name 'a' is unclear and likely a placeholder or error, which significantly hinders intent. The type annotations are helpful, but the inline 'type: ignore' comments are slightly noisy. Overall the code is concise and follows clean Python/Flask conventions, but the ambiguous 'a' property prevents a higher score.
Run 2
The code is generally readable with clear imports, a well-documented class, and a simple property. However, it has several issues: there are unused imports (BadRequest, HTTPException, RequestBase, _split_blueprint_path), the property name 'a' is completely unclear and likely a typo, the docstring for the property references unrelated config details, and the conditional logic with type ignores adds mild clutter. The structure is flat and actions are mostly one per line, but the intent of the property is ambiguous and the dead imports suggest poor organization. Overall readability is moderate but hindered by these clarity and maintenance concerns.
Run 3
The code is generally well-structured and readable. It uses clear imports (aliased as t, RequestBase, ResponseBase), docstrings, and type hints. The Response class has a clear purpose and inherits from Werkzeug's ResponseBase. The property 'a' is concise with a straightforward conditional. However, there are minor readability issues: the property name 'a' is ambiguous and does not convey intent (likely a placeholder or typo for max_cookie_size), and the type ignore comments add clutter. The nesting is minimal, length is reasonable, and action granularity is one action per line. Overall, the code is readable but could be improved with a more descriptive property name and reduced reliance on inline type-ignore comments.
Run 1
Code Structure: Imports, class configuration, and the property are logically organized. Nesting: A single conditional keeps the implementation flat and easy to follow. Clarity of intent: Type annotations, documentation, and the fallback comment explain the behavior, but the property name 'a' is opaque and does not communicate its cookie-size purpose. Code length: Executable code is concise, although the lengthy class documentation and version history add reading overhead. Action granularity: Each statement performs one action, with no compressed multi-action lines. Reading flow: The progression from defaults to application configuration and superclass fallback is natural. Limited blank-line separation between import groups and the class slightly weakens visual organization.
Run 2
Code Structure: Imports, class settings, and the property are logically organized, though several imports are unused. Nesting: The single conditional keeps the code flat and easy to follow. Clarity of intent: The class documentation and fallback comment explain the purpose, but the property name 'a' is uninformative and conflicts with the documented max_cookie_size behavior. Code length: The implementation is concise, although the lengthy class docstring and version history outweigh the small amount of executable code. Action granularity: Each statement performs one clear action, with no crowded multi-action lines. Reading flow: Configuration attributes lead naturally into the property, and the early return makes the fallback straightforward. Missing spacing between imports and the class, plus type-ignore annotations, add minor visual friction.
Run 3
Code Structure: Imports, class defaults, and the property are logically organized, although several imports are unused in this snippet. Nesting: Minimal nesting makes the conditional easy to follow. Clarity of intent: Documentation explains the response configuration and fallback behavior, but the property name 'a' is opaque and conflicts with its documented max-cookie-size purpose. Code length: Implementation is concise, though extensive historical documentation outweighs the executable code. Action granularity: Each statement performs one clear action. Reading flow: Class settings lead naturally into the property, and the early return keeps the fallback straightforward; limited separation around imports and the class, plus type-ignore annotations, introduce minor visual friction.