An Open Letter to init - I'm Leaving You for @dataclass

Stackmetric — Thu, 25 Jun 2026 15:35:50 +0000

A quick disclaimer: This article isn't an argument against init itself. Constructors remain the appropriate place for lightweight object initialization. For classes that require complex setup, resource allocation, or business logic, many developers prefer to keep init minimal and move that complexity into factory methods, builders, or dedicated initialization routines. The point here is simply that when a class exists only to represent data, @dataclass eliminates a significant amount of unnecessary boilerplate.

If you’ve been writing Python for any length of time, you’ve probably created dozens of classes that look something like this:

There is nothing inherently wrong with this code. In fact, it is exactly how many of us first learned to write Python classes. The problem is that most of the implementation has nothing to do with the problem we’re trying to solve. Instead, it consists of repetitive plumbing — constructors, string representations, and equality methods that are nearly identical from one class to the next.

The @dataclass decorator
Python’s dataclasses module, introduced in Python 3.7, eliminates nearly all of this repetitive boilerplate. Instead of manually implementing methods such as init, repr, and eq, you simply declare the object's fields as type-annotated class attributes.

The @dataclass decorator automatically generates the supporting methods, allowing you to focus on the data the class represents rather than the mechanics of managing it.

These three lines produce exactly the behavior written by hand above, and more. Instances are created the way you would expect, print readably, and compare by value rather than by identity.

Why This Matters in AI
You might be wondering why I’m so excited about saving twenty lines of code.

The answer is simple: AI applications are built from data contracts.

Every stage of an AI pipeline passes structured information from one component to another. Requests become prompts. Prompts become model outputs. Outputs become classifications, search results, metadata, routing decisions, or responses. Before long, an application contains dozens, sometimes hundreds, of small objects whose sole purpose is to represent data.

Writing constructors, string representations, and equality methods for every one of those objects isn’t difficult, but it’s definitely distracting.

As I’ve been building an AI demand intelligence platform, I’ve found that @dataclass isn't just a convenience. It encourages better software design. By removing repetitive infrastructure, it lets me think about what each object represents instead of how to implement it.

Zero Dependancy Pipelines in Pure Python

Stackmetric — Tue, 16 Jun 2026 16:57:16 +0000

Architecting the Zero-Dependency Toolset
To build a high-performance system without relying on external frameworks, we must master the native tools Python provides for structural integrity. In this section, we move beyond basic syntax to explore the core mechanics that allow us to build a robust, type-safe, and memory-efficient pipeline using nothing but the standard library.

Type Hints: Structural Contracts in Pure Python
Type hints are a formal syntax introduced in Python 3.5 that allow you to annotate your code with expected data types. Because Python is a dynamically typed language, the Python runtime does not enforce these type annotations; your code will still execute normally even if a mismatched data type is provided. Instead, type hints are designed to improve code readability, optimize IDE autocompletion, and allow static type checkers like mypy to catch bugs before production.

Why Querybase Needs Type Hints
In a typical modern AI stack, developers use third-party libraries like Pydantic to parse and validate incoming JSON metadata. Pydantic relies entirely on type hints under the hood to perform that magic.

Because we are building a Zero-Dependency Pipeline, we don’t have Pydantic or LangChain running in the background. Our data structures are native Python. If we drop type hints, we are flying completely blind. Type hints are the only tool we have to tell our code editor — and our users — exactly what shapes are allowed to pass through the system.

The Two Pathways of Type Consumption
In modern software engineering, type hints are used in one of two ways. In framework-heavy architectures, a third-party library like Pydantic reads your type hints to actively parse and validate data while the program is running. In a zero-dependency architecture, the developer and the local development environment are the sole consumers of the hints.

The diagram below illustrates the physical shift in responsibility. By bypassing the framework pathway, your pipeline avoids heavy runtime execution loops and external software dependencies, relying entirely on design-time checks to protect the core data engine.

Enumerations and Shared Vocabulary
Before components can communicate reliably, they must agree on a common language. A classifier produces an intent, a router selects a workflow, an orchestrator coordinates execution, and an analytics engine records outcomes. If each component represents these concepts using arbitrary strings, the system becomes fragile. A single typo or inconsistent naming convention can introduce failures that are difficult to detect and diagnose.

A shared vocabulary ensures that every component refers to the same concepts in the same way. Rather than allowing each part of the system to invent its own terminology, we establish a controlled set of values that all components agree to use.

What Is an Enum?
Enumerations, commonly called Enums, provide a mechanism for defining a fixed set of valid values. Rather than allowing any string to represent an intent or topic, the system explicitly defines the vocabulary that all components must use.

from enum import Enum
 class Intent(str, Enum):
     PRODUCT_RECOMMENDATION = "product_recommendation"
     TROUBLE_SHOOTING = "trouble_shooting"
     GENERAL_QUERY = "general_query"

In this example, an intent can only be one of three values. The classifier cannot invent a new intent, and downstream components do not need to guess which strings may appear. Every part of the application references the same definition.

The Problem with Strings
Without an enumeration, components typically rely on string comparisons.

if intent == "product_recommendation":
    route_to_catalog()

At first glance, this approach appears harmless. The problem emerges when values are typed manually throughout the codebase.

if intent == "product__recomendation_":
    route_to_catalog()

The application continues running, but the route is never selected. Because both values are valid strings, Python has no way to identify the mistake.

As applications grow, these inconsistencies become increasingly difficult to locate and correct.

if intent == Intent.PRODUCT_RECOMMENDATION:
    route_to_catalog()

The value must exist within the enumeration. Modern development tools can provide autocompletion, validation, and static analysis because the possible values are known in advance.

By replacing free-form strings with explicit definitions, Enums make mistakes easier to detect before the application is executed.

How Enums Improve Reliability
Enums eliminate this category of error by restricting values to a predefined vocabulary.

The value must exist within the enumeration. Modern development tools can provide autocompletion, validation, and static analysis because the possible values are known in advance.

By replacing free-form strings with explicit definitions, Enums make mistakes easier to detect before the application is executed.

Enums as Contracts
Enums provide more than type safety. They also establish formal contracts between components.

Consider the Querybase classification model:

@dataclass
class QueryClassification:
    primary_intent: Intent
    inferred_topic: Topic

This definition communicates more than structure. It defines the rules of communication between stages of the pipeline.

The classifier promises to produce a valid Intent, and the router can safely assume that only approved values will be received.

Why Enums Matter in Querybase
From an architectural perspective, Enums solve three recurring problems:

Eliminate magic strings scattered throughout the codebase.
Prevent silent failures caused by misspellings or inconsistent values.

Establish a shared vocabulary that every component uses consistently.

For Querybase, Intent and Topic are not merely implementation details. They are part of the domain model itself. The classifier, router, orchestrator, analytics engine, and API all depend upon this vocabulary remaining stable and predictable.

A well-designed software system is built upon clear contracts. Enums are one of the simplest and most effective mechanisms for establishing those contracts. By replacing arbitrary strings with a finite set of approved values, they transform implicit assumptions into explicit architectural rules.

Looking Ahead
We introduce Enums at this stage because they are one of the foundational building blocks of Querybase. Before we construct pipelines, route workflows, or classify user questions, we must first establish the vocabulary those components will use to communicate.

In Part II, we will apply these ideas directly as we build our first schema. There, Enums will become part of the contracts that govern communication throughout the entire Querybase pipeline.

DEV Community: Stackmetric

An Open Letter to init - I'm Leaving You for @dataclass

Zero Dependancy Pipelines in Pure Python