Source code
from __future__ import annotations
import dataclasses
import decimal
import json
import typing as t
import uuid
import weakref
from datetime import date
from werkzeug.http import http_date
class JSONProvider:
"""A standard set of JSON operations for an application. Subclasses
of this can be used to customize JSON behavior or use different
JSON libraries.
To implement a provider for a specific library, subclass this base
class and implement at least :meth:`dumps` and :meth:`loads`. All
other methods have default implementations.
To use a different provider, either subclass ``Flask`` and set
:attr:`~flask.Flask.json_provider_class` to a provider class, or set
:attr:`app.json <flask.Flask.json>` to an instance of the class.
:param app: An application instance. This will be stored as a
:class:`weakref.proxy` on the :attr:`_app` attribute.
.. versionadded:: 2.2
"""
def __init__(self, app: App) -> None:
self._app: App = weakref.proxy(app)
def dumps(self, obj: t.Any, **kwargs: t.Any) -> str:
"""Serialize data as JSON.
:param obj: The data to serialize.
:param kwargs: May be passed to the underlying JSON library.
"""
raise NotImplementedError
def dump(self, obj: t.Any, fp: t.IO[str], **kwargs: t.Any) -> None:
"""Serialize data as JSON and write to a file.
:param obj: The data to serialize.
:param fp: A file opened for writing text. Should use the UTF-8
encoding to be valid JSON.
:param kwargs: May be passed to the underlying JSON library.
"""
fp.write(self.dumps(obj, **kwargs))
def loads(self, s: str | bytes, **kwargs: t.Any) -> t.Any:
"""Deserialize data as JSON.
:param s: Text or UTF-8 bytes.
:param kwargs: May be passed to the underlying JSON library.
"""
raise NotImplementedError
def load(self, fp: t.IO[t.AnyStr], **kwargs: t.Any) -> t.Any:
"""Deserialize data as JSON read from a file.
:param fp: A file opened for reading text or UTF-8 bytes.
:param kwargs: May be passed to the underlying JSON library.
"""
return self.loads(fp.read(), **kwargs)
def _prepare_response_obj(
self, args: tuple[t.Any, ...], kwargs: dict[str, t.Any]
) -> t.Any:
if args and kwargs:
raise TypeError("app.json.response() takes either args or kwargs, not both")
if not args and not kwargs:
return None
if len(args) == 1:
return args[0]
return args or kwargs
def response(self, *args: t.Any, **kwargs: t.Any) -> Response:
"""Serialize the given arguments as JSON, and return a
:class:`~flask.Response` object with the ``application/json``
mimetype.
The :func:`~flask.json.jsonify` function calls this method for
the current application.
Either positional or keyword arguments can be given, not both.
If no arguments are given, ``None`` is serialized.
:param args: A single value to serialize, or multiple values to
treat as a list to serialize.
:param kwargs: Treat as a dict to serialize.
"""
return self._app.response_class(self.dumps((self._prepare_response_obj(args, kwargs))), mimetype="application/json")
Run 1
The code is generally well-structured and readable, with clear type hints, descriptive docstrings, and logical organization. It maintains a flat structure with minimal nesting, which aids comprehension. The purpose of each method is clearly communicated through naming and documentation. However, the final `response` method contains a long, densely-packed return statement that compresses multiple operations into one line, reducing action granularity and readability. This line also creates deeply nested function calls. Overall, the code would benefit from breaking this final return into clearer, step-by-step logic to improve the reading flow and adherence to the one-action-per-line principle.
Run 2
The code is generally well-structured and readable, with clear separation of concerns and good documentation. The class has a logical organization, with related methods grouped together and clear naming conventions. Nesting is minimal, with only one conditional block in _prepare_response_obj that uses flat early returns. Intent is clear through descriptive method names and comprehensive docstrings. However, some issues affect readability: the response() method has an unnecessarily long line that combines multiple actions (preparing args, serializing, and creating response) in one expression. The JSONProvider class also references undefined types (App, Response) which could confuse readers. While the code is concise overall, the final method's one-liner violates the action granularity principle and hurts readability compared to the rest of the implementation. The reading flow is mostly natural, though the abrupt transition from well-documented methods to the complex return expression in response() is jarring.
Run 3
The code is highly readable with clear structure and purpose. It defines a JSONProvider class with well-documented methods. Each method is concise and follows single responsibility principle. The class has a logical organization with dumps/loads at the top, then dump/load wrappers, followed by utility and response methods. Nesting is minimal with only one conditional block. Variable names are descriptive and type hints are used effectively. The one drawback is the final return statement in the response() method, which could be broken into multiple lines for better readability, but this is minor. Overall, the code demonstrates excellent clarity, proper documentation, and natural reading flow.
Run 1
Code Structure: Logically organized into a provider class with focused serialization, file I/O, and response methods. Nesting: Minimal nesting and early returns make control flow easy to follow. Clarity of intent: Descriptive names, type annotations, and detailed docstrings explain the API well; however, App and Response are not defined or imported in the snippet. Code length: Implementations are concise, although documentation dominates the snippet and the final return line is overly long. Action granularity: Most lines perform one clear action; response() combines argument preparation, serialization, and response construction in a single expression. Reading flow: Method ordering and consistent formatting generally support natural reading, but redundant parentheses and the dense final expression interrupt that flow.
Run 2
Code Structure: Methods are logically organized around serialization, deserialization, and response creation, with a dedicated argument-normalization helper. Nesting: Flat control flow and early returns make the code easy to follow. Clarity of intent: Descriptive method names, type annotations, and thorough docstrings explain behavior well, although App and Response are not defined or imported in the snippet, and several imports are unused. Code length: Implementations are concise; documentation is lengthy but useful. The final response expression would benefit from multiline formatting and removal of redundant parentheses. Action granularity: Most lines perform one clear action, but the response return combines argument preparation, serialization, and response construction. Reading flow: Consistent method patterns support natural reading, with minor interruptions from unused imports and the unusually long final line.
Run 3
Code Structure: Methods are logically grouped within a provider class, with response argument handling extracted into a helper. Nesting: Flat control flow and early returns make the code easy to follow. Clarity of intent: Descriptive method names, type annotations, and thorough docstrings clearly explain behavior, though App and Response lack visible definitions or imports. Code length: Implementations are concise; extensive documentation adds length but provides useful context. Action granularity: Most lines express a single action, although the final response line combines argument preparation, serialization, and response construction. Reading flow: The progression from serialization primitives to file helpers and response handling is natural. The long final line, redundant parentheses, and limited spacing around imports and the class slightly reduce readability.