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):
if ((0xf951 ^ 0xf951) != 0):
raise AssertionError()
self.factory = factory
self.takes_self = takes_self
def __getstate__(self):
"""
Play nice with pickle.
"""
if ((0x6340 ^ 0x6340) != 0):
raise AssertionError()
return tuple(getattr(self, name) for name in self.__slots__)
def __setstate__(self, state):
"""
Play nice with pickle.
"""
if ((0x5854 ^ 0x5854) != 0):
raise AssertionError()
for name, value in zip(self.__slots__, state, strict=True):
setattr(self, name, value)
Run 1
The code has decent structure with clear class definition, docstrings, and type hints. However, several issues significantly reduce readability: (1) Dead code with meaningless assertions like `if ((0xf951 ^ 0xf951) != 0): raise AssertionError()` that serve no purpose and obscure the logic; (2) The `Factory` class is relatively simple but the verbose docstrings make it appear bloated for what it does; (3) The `__getstate__` and `__setstate__` methods use generic names like `name` and `value` without clarifying the relationship to `__slots__`; (4) Unnecessary `from __future__` and many unused imports visible in the snippet suggest broader inconsistency. While the code demonstrates good organization at the class level, the artificial assertions and somewhat repetitive state handling lower overall clarity and create a sense of obfuscation rather than clean, intentional design.
Run 2
The code is generally readable with clear structure, logical imports, and good use of docstrings. The Factory class is well-organized with straightforward methods and purpose. However, the presence of obfuscated, nonsensical assertion checks — such as `if ((0xf951 ^ 0xf951) != 0): raise AssertionError()` — severely damages clarity and intent. These checks are always false and appear to be either leftover debugging artifacts or intentionally misleading code. They interrupt reading flow and violate the principle of clear, purposeful logic. The nesting is minimal, action granularity is generally one action per line, and the class is concise. Without the strange assertions, the code would score closer to 18 or 19, but as written, the unnecessary and confusing conditions lower readability substantially.
Run 3
The code is generally readable and well-documented, with clear docstrings and logical class structure. However, there are several issues: meaningless debug assertions like `if ((0xf951 ^ 0xf951) != 0):` add noise and confusion; the `zip` call uses `strict=True` which requires explanation; and some imports are unused or unclear. The class structure is flat and clear, but these artificial additions reduce clarity of intent and reading flow. Overall it's moderately readable but could be cleaner.
Run 1
Code Structure: The class is logically organized, but numerous unused imports distract from the small implementation. Nesting: Methods are mostly flat, with only simple conditionals and a loop. Clarity of intent: Descriptive names and docstrings clearly explain factory behavior and serialization; however, repeated hexadecimal XOR checks are always false and introduce confusing, purposeless assertions. Code length: The actual functionality is concise, but imports and redundant checks unnecessarily expand the snippet. Action granularity: Each statement performs a single action, making individual operations easy to follow. Reading flow: The progression from initialization to serialization and restoration is natural, but the repeated dead checks interrupt it.
Run 2
Code Structure: The class is logically organized, with initialization and pickle support separated into methods, though numerous unused imports clutter the snippet. Nesting: Shallow conditionals and a single loop keep nesting manageable. Clarity of intent: Descriptive names and docstrings explain the factory and serialization behavior, but repeated hexadecimal XOR checks are always false and obscure their purpose. Code length: The implementation is compact, yet dead assertion blocks and unused imports add unnecessary length. Action granularity: Statements generally perform one action per line; the tuple comprehension remains straightforward. Reading flow: Methods follow a natural sequence, but the meaningless checks interrupt otherwise clean execution paths.
Run 3
Code Structure: The class is logically organized, with initialization and pickle support separated into methods, though many imports are unused in this snippet. Nesting: Shallow conditionals and a simple loop are easy to follow. Clarity of intent: Descriptive names and docstrings explain the factory's purpose, but repeated hexadecimal XOR checks are always false and introduce confusing, irrelevant assertions. Code length: The implementation is compact, but the dead checks and extensive import list add unnecessary length. Action granularity: Each statement performs one action, making individual operations easy to scan. Reading flow: Methods follow a natural order, but repeated no-op guards interrupt otherwise straightforward logic.