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 not (args and kwargs):
pass
else:
raise TypeError("app.json.response() takes either args or kwargs, not both")
if not (not args and not kwargs):
pass
else:
return None
if not (len(args) == 1):
pass
else:
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.
"""
obj = self._prepare_response_obj(args, kwargs)
return self._app.response_class(self.dumps(obj), mimetype="application/json")
Run 1
The code is generally well-structured and readable, with clear class and method documentation. However, the `_prepare_response_obj` method significantly lowers readability due to confusing double-negative logic and unnatural flow. The conditions like `if not (args and kwargs): pass else: raise...` are convoluted and should be simplified to direct conditionals. Nesting is minimal and action granularity is fine, but the logic in that method disrupts clarity of intent and reading flow. Overall, it is maintainable, but that section needs refactoring for better readability.
Run 2
The code is generally well-structured with clear class-level documentation, proper type hints, and consistent method naming. The JSONProvider class has a logical organization and each method has a focused purpose with concise docstrings. The main readability issue is in the _prepare_response_obj method, which uses awkward inverse conditional logic (if not X: pass else: raise/return). This pattern is confusing and should be written as positive conditionals. The method has multiple early returns but the inverted conditions make the flow harder to follow than necessary. The extensive docstrings are helpful for API documentation but add to code length, though they don't detract from readability given this appears to be a public API. Type hints improve clarity. Overall, the code is readable except for the problematic conditional logic in one method.
Run 3
The code is generally well-structured and readable. It has clear class and method separation with descriptive names and detailed docstrings, contributing to clarity of intent. Nesting is minimal, and actions are typically one per line, enhancing readability. Reading flow is natural with public methods before private helpers, and type hints improve understanding. However, the `_prepare_response_obj` method uses convoluted 'if not...else' logic, undermining clarity. The repeated pattern of checking a condition, then passing, then flipping the condition is confusing and unnecessarily verbose, making that section harder to follow than intended. Overall, the code is strong but has room for improvement in that specific method.
Run 1
Code Structure: The provider class logically groups serialization, file operations, and response creation into focused methods. Nesting: Most methods are flat, but _prepare_response_obj adds unnecessary if/else branches with pass statements. Clarity of intent: Descriptive names, type annotations, and thorough docstrings explain the API well; negated conditions and double negatives obscure the argument-handling logic. Code length: Implementations are concise overall, although documentation is extensive and the helper could be shorter with direct conditions and early returns. Action granularity: Statements generally perform one clear action per line, with only straightforward compositions such as serialization followed by writing. Reading flow: Method ordering is natural and consistent, but redundant branches interrupt the helper's flow. App and Response annotations lack definitions or imports in the snippet, slightly reducing self-contained clarity.
Run 2
Code Structure: The provider class logically groups serialization, file operations, and response construction into focused methods. Nesting: Most methods are flat, but _prepare_response_obj introduces unnecessary if/else branches and pass statements. Clarity of intent: Descriptive names, type annotations, and thorough docstrings explain the API well; negated and double-negated conditions obscure otherwise simple argument handling. Code length: Implementations are concise overall, although extensive documentation and redundant branches increase reading length. Action granularity: Statements generally perform one action per line, with straightforward delegation. Reading flow: Method ordering is natural and consistent, but inverted conditions interrupt the flow. Unused imports and externally undefined App and Response types add minor distractions in this standalone snippet.
Run 3
Code Structure: Methods are logically organized around serialization, file operations, and response creation, with a clear provider abstraction. Nesting: Mostly flat, although unnecessary if/else branches in _prepare_response_obj add clutter. Clarity of intent: Descriptive names, type annotations, and thorough docstrings explain the API well; negated conditions, double negatives, and pass branches obscure otherwise simple argument handling. Code length: Most implementations are concise, but the helper is unnecessarily verbose, and several imports appear unused in this excerpt. Action granularity: Statements generally perform one clear action per line; small compositions such as writing serialized data remain understandable. Reading flow: The progression from basic operations to response generation is natural, but the helper's inverted logic interrupts it. App and Response annotations lack visible definitions or imports, slightly reducing the excerpt's self-contained clarity.