Python 25-line dataclass alternative reveals subtle pitfalls

Python’s @dataclass decorator streamlines class creation by auto-generating common methods like __init__ and __repr__, but what if you prefer a functional approach? One developer crafted a 25-line solution that transforms keyword arguments into a class on the fly—without decorators or boilerplate. The result is elegant, but a deeper look uncovers three critical flaws that could disrupt hashing behavior, representation accuracy, and equality comparisons.

A functional twist on class creation

The approach replaces decorators with a function that returns a class. By passing keyword arguments to this function, you define both field names and their default values directly:

Klass = Klass(a=1, b=2)  # Fields become defaults

This design allows for flexible instance overrides while preserving class-level defaults. For example:

Klass(a=3).a  # Returns 3 (instance override)
Klass().a     # Returns 1 (class-level default)

The implementation avoids metaclasses or imports, relying solely on Python’s built-in type() constructor. Yet beneath its simplicity, the pattern introduces subtle bugs that challenge expectations around hashing, string representation, and object equality.

How the 25-line solution works

The function Klass(**fields) constructs a class dynamically using type("DataClass", (object,), fields). This creates a class where the passed keyword arguments become class-level attributes. An inner class _ then inherits from this dynamically generated class, adding methods like __init__, __eq__, __hash__, and __repr__ to manage instance behavior.

The closure over fields ensures these methods can access the original keyword arguments without additional storage. This design mirrors how frameworks like Django handle default values, keeping defaults on the class and overrides on the instance.

The three hidden bugs

Bug 1: Hash collisions undermine dictionary performance

The __hash__ method computes a hash based on the closure’s fields dictionary rather than the actual instance state:

def __hash__(self):
    return hash(tuple(fields[k] for k in fields["__data__"]))

This means all instances of the same class—regardless of their attribute values—return identical hashes. While Python allows hash collisions, this behavior degrades dictionary performance to O(n) complexity, as all keys collide into the same bucket. For small datasets, the impact is negligible, but scaling to thousands of objects reveals a critical flaw.

Bug 2: __repr__ misrepresents instance state

The __repr__ method formats the closure’s fields dictionary instead of the instance’s __dict__:

def __str__(self):
    return "&data.{}({})".format(self.__class__.__name__, fields)

This causes the output to display default values even when instances override them. For example, if you create x = Klass(a=99) and print it, the representation will incorrectly show a: 1 instead of a: 99. Correcting this requires merging both fields and self.__dict__ in the string formatting.

Bug 3: __eq__ fails to compare resolved attributes

Equality checks rely solely on __dict__ comparisons, which miss inherited class attributes:

def __eq__(self, other):
    return self.__dict__ == other.__dict__

This leads to unexpected results. Two objects with identical effective values may compare as unequal if one defines attributes at the instance level while the other inherits them from the class. For instance:

Klass(a=1, b=2)
Klass() == Klass(a=1, b=2)  # Returns False (unequal __dict__)

Fixing this requires comparing resolved attribute values, such as using getattr() to fetch each field’s current value.

Why this pattern matters (despite the flaws)

While the bugs highlight real risks, the underlying approach offers valuable lessons about Python’s object model. The technique demonstrates four key concepts:

• Classes as first-class objects: Functions can return classes, and type() acts as a dynamic class constructor.
• Closures in class definitions: Methods can access the enclosing function’s scope without explicit storage.
• Class vs. instance attribute separation: Defaults live on the class, while overrides reside on the instance.
• The purpose of `@dataclass`: The standard library’s implementation handles edge cases—like __hash__ stability and attribute resolution—far more robustly than a 25-line alternative.

Exploring the source code of Python’s dataclasses.py module reveals a more nuanced approach to generating these methods, including handling inheritance, freezing, and tuple-based comparisons.

When to use (or avoid) this technique

This pattern is not production-ready. The three bugs alone disqualify it for any serious use case. Instead, rely on established tools like @dataclass or the attrs library, which address these pitfalls through careful design.

However, as an educational exercise, this 25-line implementation serves as a powerful teaching tool. Typing it out, identifying the bugs, and understanding their fixes provides deeper insight into Python’s object-oriented mechanics. It’s a reminder that even simple patterns can harbor hidden complexities—and that sometimes, the standard library’s solutions exist for good reason.