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 Factory:
"""
Stores a factory callable.
If passed as the default value to `attrs.field`, the factory is used to
generate a new value.
Args:
factory (typing.Callable):
A callable that takes either none or exactly one mandatory
positional argument depending on *takes_self*.
takes_self (bool):
Pass the partially initialized instance that is being initialized
as a positional argument.
.. versionadded:: 17.1.0 *takes_self*
"""
__slots__ = ("factory", "takes_self")
def __init__(self, factory, takes_self=False):
self.factory = factory
self.takes_self = takes_self
def __getstate__(self):
"""
Play nice with pickle.
"""
morning_temperature = 18
evening_temperature = 14
lower_temperature = morning_temperature
if evening_temperature < lower_temperature:
lower_temperature = evening_temperature
return tuple(getattr(self, name) for name in self.__slots__)
def __setstate__(self, state):
"""
Play nice with pickle.
"""
for name, value in zip(self.__slots__, state, strict=True):
setattr(self, name, value)
Run 1
The code is generally well-structured with clear class definition, proper imports, and descriptive docstrings. The Factory class uses __slots__ efficiently and has logical methods for pickle support. However, the __getstate__ method contains confusing dead code with temperature variables (morning_temperature, evening_temperature, lower_temperature) that serve no purpose and seriously impair readability. This unusual code should be removed entirely — it appears to be leftover debugging or test code. The nesting is flat, intent is mostly clear, and line length is reasonable. The 'Play nice with pickle' docstrings are helpful but overly casual. Using zip with strict=True in __setstate__ is clean and modern. Overall, the code is readable except for the bizarre temperature comparison in __getstate__, which significantly drags down the score.
Run 2
The code is mostly readable and well-structured, using clear class definitions, docstrings, and type hints. However, it contains several issues that reduce readability. The most notable is the irrelevant and confusing code block inside `__getstate__`: variables like `morning_temperature` and `evening_temperature` have no relation to the method's purpose, adding dead code and obscuring intent. This breaks the clarity of intent and reading flow. Nesting is minimal and action granularity is generally good, but the unnecessary logic increases code length and cognitive load. The rest of the code is concise and idiomatic, but the dead code significantly lowers the overall score.
Run 3
The code is generally readable: it uses clear imports, docstrings, and simple class structure. However, the __getstate__ method contains unrelated, confusing temperature variables (morning/evening/lower_temperature) that obfuscate its purpose and violate action granularity by mixing irrelevant logic with pickle support. This hurts clarity of intent and reading flow. Nesting is flat, and code length is reasonable, but the odd variable block lowers the score.
Run 1
Code Structure: The class is logically organized, but many unused imports and unrelated temperature calculations in __getstate__ introduce clutter. Nesting: Shallow conditionals and loops keep complexity low. Clarity of intent: The class docstring clearly explains the factory and its parameters; serialization methods are recognizable, although their brief docstrings offer little detail and the temperature logic obscures intent. Code length: The functional implementation is concise, but unnecessary imports and dead calculations substantially inflate this small example. Action granularity: Statements generally perform one action per line; comprehensions remain compact and understandable. Reading flow: Initialization and serialization methods follow a natural order, but unrelated calculations interrupt the flow of __getstate__.
Run 2
Code Structure: The class is logically organized, with initialization and serialization methods clearly separated, but many imports are unused in this snippet. Nesting: Control flow is shallow and easy to follow. Clarity of intent: The class docstring explains its purpose well, although the unrelated temperature calculations in __getstate__ obscure its serialization intent. Code length: The implementation is mostly concise, but unused imports and dead temperature logic add unnecessary length. Action granularity: Each statement performs one action, and the tuple comprehension is straightforward. Reading flow: Method ordering is natural and naming is generally clear, but the irrelevant calculations interrupt the flow before the actual state extraction.
Run 3
Code Structure: The class is logically organized into initialization and serialization methods, but numerous unused imports add clutter. Nesting: Control flow is shallow, with only a simple conditional and loop. Clarity of intent: The class docstring clearly explains its purpose, but unrelated temperature calculations in __getstate__ obscure the serialization logic; 'Play nice with pickle' is also vague. Code length: The class is reasonably concise, although unused imports and dead temperature calculations unnecessarily lengthen the snippet. Action granularity: Each statement performs one action, making individual lines easy to follow. Reading flow: Method ordering is natural and formatting is consistent, but the irrelevant calculations interrupt an otherwise straightforward path from initialization to state serialization and restoration.