FAQ

Why not just use dataclasses?

You often should — see Migration: from dataclasses. inito adds accessors, a fluent builder, and the ability to pick individual capabilities (@Getter alone, @ToString alone, …) rather than one all-or-nothing decorator.

Does inito validate field values?

No. inito generates boilerplate (constructors, repr, equality, hashing, accessors, builders) — it never inspects or validates the values passed in, only the declared fields (once, at decoration time). If you need validation, that belongs in __post_init__ (works fine alongside @dataclass), a custom __init__ override, or a dedicated validation library.

Is it safe to use @Data in a hot path?

Yes — see Performance. Reflection and code generation happen exactly once, at decoration time. Constructing instances, reading attributes, comparing, and hashing all run the same generated Python bytecode a handwritten class would, with no per-call overhead.

Can I add my own methods to a decorated class?

Yes, normally:

from inito import Data


@Data
class User:
    name: str
    age: int

    def greet(self) -> str:
        return f"Hello, {self.name}"

inito only ever attaches the specific members each decorator is responsible for (e.g. @Data never touches a method you define yourself under a name it doesn’t generate, like greet). It will overwrite a method it does generate (e.g. __repr__) if you also define one by hand, since decoration always attaches its generated version last.

Why does @Builder alone not give me a nice repr?

By design — see the @ToString + @Builder example. Each decorator does one focused thing, matching Lombok; stack @ToString (or @Data) alongside @Builder for a readable repr.

Does inito work with generic classes (Generic[T])?

Yes — decorating a Generic[T] class works normally; inito only inspects declared fields, not type-parameter machinery.