Source code
from __future__ import annotations
import abc
import contextlib
import enum
import itertools
import linecache
import sys
import types
import unicodedata
import weakref
from collections.abc import Callable, Mapping
from functools import cached_property
from typing import Any, NamedTuple, TypeVar
from . import _compat, _config, setters
from ._compat import (
PY_3_11_PLUS,
PY_3_13_PLUS,
_AnnotationExtractor,
_get_annotations,
_lazy_is_generator,
get_generic_base,
)
from .exceptions import (
DefaultAlreadySetError,
FrozenInstanceError,
NotAnAttrsClassError,
UnannotatedAttributeError,
)
class Converter:
"""
Stores a converter callable.
Allows for the wrapped converter to take additional arguments. The
arguments are passed in the order they are documented.
Args:
converter (Callable): A callable that converts the passed value.
takes_self (bool):
Pass the partially initialized instance that is being initialized
as a positional argument. (default: `False`)
takes_field (bool):
Pass the field definition (an :class:`Attribute`) into the
converter as a positional argument. (default: `False`)
.. versionadded:: 24.1.0
"""
__slots__ = (
"__call__",
"_first_param_type",
"_global_name",
"converter",
"takes_field",
"takes_self",
)
def __init__(self, c, *, d=False, e=False):
self.converter = c
self.takes_self = d
self.takes_field = e
f = _AnnotationExtractor(c)
self._first_param_type = f.get_first_param_type()
if not (self.takes_self or self.takes_field):
self.__call__ = lambda value, _, __: self.converter(value)
elif self.takes_self and not self.takes_field:
self.__call__ = lambda value, instance, __: self.converter(
value, instance
)
elif not self.takes_self and self.takes_field:
self.__call__ = lambda value, __, field: self.converter(
value, field
)
else:
self.__call__ = self.converter
g = f.get_return_type()
if g is not None:
self.__call__.__annotations__["return"] = g
@staticmethod
def a(h: str) -> str:
"""
Return the name that a converter for an attribute name *attr_name*
would have.
"""
return f"__attr_converter_{h}"
def b(self, i: str, j: str) -> str:
"""
Return a string that calls the converter for an attribute name
*attr_name* and the value in variable named *value_var* according to
`self.takes_self` and `self.takes_field`.
"""
if not (self.takes_self or self.takes_field):
return f"{self.a(i)}({j})"
if self.takes_self and self.takes_field:
return f"{self.a(i)}({j}, self, attr_dict['{i}'])"
if self.takes_self:
return f"{self.a(i)}({j}, self)"
return f"{self.a(i)}({j}, attr_dict['{i}'])"
def __getstate__(self):
"""
Return a dict containing only converter and takes_self -- the rest gets
computed when loading.
"""
return {
"converter": self.converter,
"takes_self": self.takes_self,
"takes_field": self.takes_field,
}
def __setstate__(self, k):
"""
Load instance from state.
"""
self.__init__(**k)
Run 1
The code is poorly readable due to cryptic naming (single-letter parameters c, d, e, f, g, h, i, j, k; methods a and b), unclear intent, and confusing action granularity. The structure is somewhat logical with dunder methods, but the one-letter names obscure meaning, making the parameter `d` and `e` ambiguous — likely they mean takes_self and takes_field. The nested lambda assignments mix multiple actions per line, reducing clarity. Method names `a` and `b` give no indication of their purpose, though their docstrings are helpful; but the names fail to convey intent. The `__getstate__` return dictionary omits recomputed attributes oddly. The reading flow is hindered because the public API (`Converter`) is mixed with internal helpers, and the brevity of names trades away understandability for length. Nesting is shallow, but clarity suffers severely from opacity.
Run 2
This code is largely unreadable due to several serious issues. Function and parameter names (a, b, c, d, e, f, g, h, i, j, k) are meaningless, obscuring intent. The code combines unclear naming with redundant branching logic in __init__ where lambdas are assigned to __call__ with placeholders (_, __). Methods like a() and b() lack descriptive purposes despite having docstrings. The Converter class mixes responsibilities (callable wrapping, code generation, serialization) without clear separation. Nesting is moderate but the action granularity and reading flow are poor due to cryptic identifiers and inconsistent parameter ordering. The code uses slots and annotations but this doesn't compensate for the opaque structure and naming.
Run 3
The code is poorly readable due to several factors. Naming is terrible: single-letter parameter names (c, d, e, f, g, h, i, j, k) and method names (a, b) completely obscure intent, despite some docstrings explaining them. The Converter.__init__ has confusing flag names (d, e) that map to takes_self and takes_field via cryptic conditional lambda assignments, creating deeply confusing branching logic and multiple actions per line in the lambda assignments. The code also mixes abstraction levels -- type introspection, lambda assignment, and state management are interleaved. While docstrings and comments exist, they mostly explain what, not why, and do not compensate for unclear identifiers. The reading flow is disrupted by the random placement of helper methods after __init__ and unclear ordering. Some structural organization exists (slots, separate methods for string generation), but the naming and dense conditional logic overshadow these positive qualities.
Run 1
Code Structure: The class is logically organized into initialization, call-string generation, and serialization methods, although numerous unused imports add clutter. Nesting: Shallow conditional branches keep control flow easy to follow. Clarity of intent: Descriptive attribute names and detailed docstrings explain the purpose, but single-letter method names, parameters, and local variables obscure meaning. Documentation refers to parameter names absent from the signatures, and __setstate__ passes descriptive keyword names that __init__ does not accept, undermining coherence. Code length: The implementation is reasonably concise, though imports and repetitive conditional logic add overhead. Action granularity: Statements generally perform one action per line; the short lambdas are manageable. Reading flow: Methods follow a natural sequence and formatting is consistent, but readers must repeatedly map cryptic identifiers to documented concepts.
Run 2
Code Structure: The class is logically organized into initialization, converter-call generation, and serialization, but numerous unused imports add clutter. Nesting: Shallow conditionals and early returns keep control flow manageable. Clarity of intent: Descriptive class attributes and docstrings help, but single-letter method and parameter names obscure meaning. Documentation references names absent from signatures, and __setstate__ passes descriptive dictionary keys to an incompatible __init__ signature, undermining confidence in intent. Code length: The class is reasonably concise, though verbose documentation and unrelated imports increase reading overhead. Action granularity: Statements generally perform one action each, with clearly separated assignments and returns. Reading flow: Methods follow a sensible sequence, but dynamic __call__ assignment, annotation mutation, and generated call strings require extra mental effort. Overall, organization is solid, but opaque naming and documentation/signature mismatches significantly reduce readability.
Run 3
Code Structure: The class is logically organized into initialization, call-string generation, and serialization methods, though numerous unrelated imports add clutter. Nesting: Conditional branches are shallow, and early returns keep the helper method flat. Clarity of intent: Descriptive attributes and extensive docstrings explain the converter's purpose, but single-letter method and parameter names obscure meaning. Documentation references parameter names absent from the signatures, and __setstate__ passes descriptive keys that do not match __init__ parameters, disrupting comprehension. Code length: The implementation is reasonably concise, although documentation and imports outweigh the small amount of functional code. Action granularity: Most lines perform one action, with multiline lambdas and calls formatted clearly. Reading flow: Methods follow a natural progression, but readers must repeatedly map cryptic names to documented concepts and understand dynamically assigned __call__ behavior.