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 DefaultJSONProvider(JSONProvider):
"""Provide JSON operations using Python's built-in :mod:`json`
library. Serializes the following additional data types:
- :class:`datetime.datetime` and :class:`datetime.date` are
serialized to :rfc:`822` strings. This is the same as the HTTP
date format.
- :class:`uuid.UUID` is serialized to a string.
- :class:`dataclasses.dataclass` is passed to
:func:`dataclasses.asdict`.
- :class:`~markupsafe.Markup` (or any object with a ``__html__``
method) will call the ``__html__`` method to get a string.
"""
default: t.Callable[[t.Any], t.Any] = staticmethod(_default)
"""Apply this function to any object that :meth:`json.dumps` does
not know how to serialize. It should return a valid JSON type or
raise a ``TypeError``.
"""
ensure_ascii = True
"""Replace non-ASCII characters with escape sequences. This may be
more compatible with some clients, but can be disabled for better
performance and size.
"""
sort_keys = True
"""Sort the keys in any serialized dicts. This may be useful for
some caching situations, but can be disabled for better performance.
When enabled, keys must all be strings, they are not converted
before sorting.
"""
compact: bool | None = None
"""If ``True``, or ``None`` out of debug mode, the :meth:`response`
output will not add indentation, newlines, or spaces. If ``False``,
or ``None`` in debug mode, it will use a non-compact representation.
"""
mimetype = "application/json"
"""The mimetype set in :meth:`response`."""
def a(self, d: t.Any, **e: t.Any) -> str:
"""Serialize data as JSON to a string.
Keyword arguments are passed to :func:`json.dumps`. Sets some
parameter defaults from the :attr:`default`,
:attr:`ensure_ascii`, and :attr:`sort_keys` attributes.
:param obj: The data to serialize.
:param kwargs: Passed to :func:`json.dumps`.
"""
e.setdefault("default", self.default)
e.setdefault("ensure_ascii", self.ensure_ascii)
e.setdefault("sort_keys", self.sort_keys)
return json.dumps(d, **e)
def b(self, f: str | bytes, **g: t.Any) -> t.Any:
"""Deserialize data as JSON from a string or bytes.
:param s: Text or UTF-8 bytes.
:param kwargs: Passed to :func:`json.loads`.
"""
return json.loads(f, **g)
def c(self, *h: t.Any, **i: t.Any) -> Response:
"""Serialize the given arguments as JSON, and return a
:class:`~flask.Response` object with it. The response mimetype
will be "application/json" and can be changed with
:attr:`mimetype`.
If :attr:`compact` is ``False`` or debug mode is enabled, the
output will be formatted to be easier to read.
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.
"""
j = self._prepare_response_obj(h, i)
k: dict[str, t.Any] = {}
if (self.compact is None and self._app.debug) or self.compact is False:
k.setdefault("indent", 2)
else:
k.setdefault("separators", (",", ":"))
return self._app.response_class(
f"{self.a(j, **k)}\n", mimetype=self.mimetype
)
Run 1
The code suffers from significant readability issues. While the class-level docstrings and attribute documentation are clear, the functions themselves use cryptic single-letter names ('a', 'b', 'c') and meaningless variable names ('d', 'e', 'f', 'g', 'h', 'i'). The method names completely obscure their intent (dumps, loads, response). The reading flow is severely disrupted by the unexplained variable renaming, forcing the reader to mentally map back to the original concepts. Although the logic in function 'c' is flat and relatively straightforward, the overall clarity of intent is poor. The code length is acceptable but would benefit from proper naming conventions. Score reflects functional but obfuscated code that requires significant mental overhead.
Run 2
This code is extremely poor in readability. Method names are reduced to single letters ('a', 'b', 'c') which completely obscures their purpose despite detailed docstrings. Parameters use meaningless names like 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k'. The class structure is well-organized and docstrings are thorough, but this contrast makes the obfuscated naming even more jarring. There's a disconnect between the helpful documentation and the cryptic implementation. The method 'a' mentions ':param obj:' but the actual parameter is 'd'. Logical flow exists but is impossible to follow naturally when every identifier requires cross-referencing docstrings. Nesting and length are acceptable, but the lack of clear intent in naming makes this unmaintainable for any developer who must actually work with the code.
Run 3
The code is extremely difficult to read due to meaningless single-letter identifiers (d, e, f, g, h, i, j, k) replacing descriptive parameter names like obj, kwargs, s, args. Method names are also obfuscated (a, b, c instead of dumps, loads, response). While the structure is logical and the docstrings are helpful, the obfuscated names destroy clarity of intent and require constant mental mapping. Nesting is minimal and actions are generally one per line, but the overall readability is severely compromised by the naming choices.
Run 1
Code Structure: Logically organized into a provider class with configuration attributes and separate serialization, deserialization, and response methods. Nesting: Shallow, with only one straightforward conditional. Clarity of intent: Detailed docstrings and type hints explain behavior, but single-letter method and variable names obscure intent; documented parameter names also differ from actual signatures. Referenced definitions such as JSONProvider and _default are absent from the snippet. Code length: Implementations are concise, although extensive documentation dominates the small amount of logic and several imports appear unused. Action granularity: Each statement performs one clear action, with no crowded compound statements. Reading flow: Consistent formatting and a natural configuration-to-method sequence help navigation, but opaque identifiers force readers to repeatedly consult docstrings and trace values.
Run 2
Code Structure: Logically organized into configuration attributes and three focused methods, although undefined external dependencies obscure context. Nesting: Shallow, with only one straightforward conditional. Clarity of intent: Extensive docstrings explain serialization behavior, but single-letter method and variable names hide meaning, and documented parameter names do not match signatures. Code length: Implementations are concise; documentation is lengthy but mostly useful, while several unused imports add clutter. Action granularity: Each statement generally performs one action, with no compressed multi-statement lines. Reading flow: Consistent formatting and a natural configuration-to-methods progression help navigation, but cryptic identifiers and references to absent definitions interrupt comprehension.
Run 3
Code Structure: The class logically groups configuration and serialization, deserialization, and response creation methods. Nesting: Minimal nesting and a single straightforward conditional keep complexity low. Clarity of intent: Extensive docstrings and type hints explain behavior, but single-letter method and variable names obscure meaning. Docstring parameter names do not match actual signatures, and referenced methods such as response are renamed, creating confusion. Code length: Implementations are concise; documentation is substantial but mostly useful. Some imports appear unused, and dependencies such as JSONProvider and _default are not shown. Action granularity: Each line generally performs one clear action, with configuration updates separated cleanly. Reading flow: The progression from configuration to JSON operations to response construction is natural, but opaque identifiers force readers to repeatedly consult documentation.