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, converter, *, takes_self=False, takes_field=False):
self.converter = converter
self.takes_self = takes_self
self.takes_field = takes_field
ex = _AnnotationExtractor(converter)
self._first_param_type = ex.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
rt = ex.get_return_type()
if not (rt is not None):
pass
else:
self.__call__.__annotations__["return"] = rt
@staticmethod
def _get_global_name(attr_name: str) -> str:
"""
Return the name that a converter for an attribute name *attr_name*
would have.
"""
return f"__attr_converter_{attr_name}"
def _fmt_converter_call(self, attr_name: str, value_var: 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 (not (self.takes_self or self.takes_field)):
pass
else:
return f"{self._get_global_name(attr_name)}({value_var})"
if not (self.takes_self and self.takes_field):
pass
else:
return f"{self._get_global_name(attr_name)}({value_var}, self, attr_dict['{attr_name}'])"
if not (self.takes_self):
pass
else:
return f"{self._get_global_name(attr_name)}({value_var}, self)"
return f"{self._get_global_name(attr_name)}({value_var}, attr_dict['{attr_name}'])"
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, state):
"""
Load instance from state.
"""
self.__init__(**state)
Run 1
The code has clear structure overall with logical class organization, but several readability issues stand out. The `Converter` class has a clear purpose and good docstrings, but the use of artificial boolean checks like `if not (rt is not None): pass else: ...` and `if not (not (self.takes_self or self.takes_field)): pass else: ...` is needlessly convoluted and severely harms readability. These should simply use standard `if rt is not None:` and `if not (self.takes_self or self.takes_field):` patterns. The constructor uses conditional lambda assignments on `self.__call__` which reduces clarity compared to separate method definitions or a single dispatch pattern. Long lines exceeding typical style guidelines (e.g., in `_fmt_converter_call`) reduce readability. Redundant conditional branches with empty bodies suggest generated or intentionally obfuscated code. While the class documentation is helpful and intent is mostly clear, the style choices create unnecessary cognitive overhead and violate common Python idioms.
Run 2
The code is poorly readable due to several factors. The Converter class has confusing conditional logic in __init__ that assigns lambdas with cryptic underscores and modifies __call__.__annotations__ implicitly. The _fmt_converter_call method uses inverted 'if not (condition): pass else: return' patterns instead of straightforward 'if condition: return' guards, which obscures intent and adds noise. Multiple actions are packed into single lines (e.g., annotation assignment). While the class docstring and some method names are clear, the overall flow feels tangled, with excessive imports and inconsistent style contributing to clutter. Nesting is shallow, but the awkward conditional structures make reading flow unnatural and intent harder to grasp than necessary.
Run 3
The code is structurally organized with clear imports, docstrings, and type hints, aiding overall clarity. However, several parts significantly hurt readability. The conditional logic using `if not (condition): pass else: ...` is convoluted and inverted, making intent harder to follow. The repeated use of lambda assignments in `__init__` creates dense, multi-line expressions that reduce action granularity. Some methods like `_fmt_converter_call` are longer than necessary due to awkward branching, and the flow is interrupted by these patterns. While the class design is mostly logical, the nesting and control flow could be simplified, and the `if`/`else` inversion is confusing. Overall, it is readable in structure but suffers from unclear conditional style and overly compact lambda definitions.
Run 1
1. Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, although numerous imports are unused in this snippet. 2. Nesting: Nesting is shallow, but repeated negated conditions with pass/else branches introduce unnecessary complexity. 3. Clarity of intent: Descriptive method names and detailed docstrings explain the converter's purpose; double negatives, abbreviated variables such as ex and rt, and a serialization docstring that omits takes_field reduce clarity. 4. Code length: Mostly compact, but redundant pass branches and verbose conditionals unnecessarily expand straightforward logic. 5. Action granularity: Statements generally perform one action per line; lambda wrappers are concise and reasonably understandable. 6. Reading flow: Method grouping and formatting support natural reading, but inverted conditions interrupt the flow, especially in _fmt_converter_call. Direct positive conditions and early returns would substantially improve readability.
Run 2
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, although numerous imports are unused in this excerpt. Nesting: Nesting is shallow, but repeated negated conditions with pass/else branches complicate otherwise simple decisions. Clarity of intent: Descriptive method names and detailed docstrings explain the purpose; double negation, abbreviated variables such as ex and rt, and placeholder lambda arguments reduce clarity. Code length: Documentation is useful, but redundant branches and repeated formatting expressions add unnecessary length. Action granularity: Statements generally perform one action per line, with appropriately separated assignments and returns. Reading flow: Method order is natural, but inverted conditions interrupt the flow and require mental simplification. Direct positive conditions and early returns would substantially improve readability.
Run 3
Code Structure: The class is logically organized into initialization, call formatting, and serialization methods, although numerous unused imports add clutter. Nesting: Generally shallow, but redundant if/pass/else branches complicate otherwise simple decisions. Clarity of intent: Descriptive method names and docstrings explain the converter's purpose; double negations, placeholder parameter names, and dynamically assigned lambdas make details harder to understand. The serialization docstring also omits takes_field. Code length: Reasonable overall, but unnecessary branches and imports inflate it. Action granularity: Most lines perform a single action, with multiline calls formatted clearly. Reading flow: Methods follow a natural progression, but inverted conditions and no-op branches interrupt comprehension, particularly in _fmt_converter_call.