Data Transfer Objects: Solutions

If you add z: float and leave the call as Point(1.0, 2.0), Python raises a TypeError at that call for the missing positional argument 'z', and ty reports a missing-argument on the call before the script runs. A field declared without a default becomes a required parameter of the generated __init__(), so the solution passes three arguments to every Point(...) call.

# exercise_2.py
from dataclasses import dataclass

@dataclass
class Point:
    x: float
    y: float
    z: float

p = Point(1.0, 2.0, 3.0)
print(p)
#: Point(x=1.0, y=2.0, z=3.0)
p.x = 3.5
print(p == Point(3.5, 2.0, 3.0))
#: True

@dataclass reads whatever fields the class body declares and generates __init__(), __repr__(), and __eq__() to match. Adding z: float extends the constructor to three positional arguments, the repr() to three fields, and the equality comparison to three values, with no other code to update.

If you assign a longer list to the field, as in toast.steps = toast.steps + ["butter"], Python raises an AttributeError (can't set attribute) and the type checker reports the assignment, the same refusal color_namedtuple.py shows for red.r = 9. That attempt tests the record’s immutability, which holds. The solution calls append() instead, which assigns nothing to the record and edits the field’s list in place.

# exercise_3.py
from typing import NamedTuple
from exceptions import expected

class Recipe(NamedTuple):
    name: str
    steps: list[str]

toast = Recipe("Toast", ["slice", "heat"])
toast.steps.append("butter")
print(toast)
#: Recipe(name='Toast', steps=['slice', 'heat', 'butter'])
with expected(TypeError):
    key = {toast: "breakfast"}
#: [TypeError] cannot use 'Recipe' as a dict key (unhashable
#: type: 'list')

Mutate through the field. The record changed, and nothing objected. NamedTuple refuses to rebind toast.steps. It says nothing about the list that field references, so append() edits that list through the record. Both the type checker and Python stay silent, because append() mutates the list instead of assigning to a field.

Hash the record. Using the record as a dict key raises a TypeError, whose message names the cause: cannot use 'Recipe' as a dict key (unhashable type: 'list'). Hashing a tuple hashes each element, so a Recipe is hashable only when every field is. The list has no hash, so the record has none either.

The silent append() and the TypeError are one fact seen twice. The immutability a NamedTuple gives you stops at the field, and a field pointing at a mutable object hands that object’s mutability back. frozen=True in Rethinking Objects is shallow the same way. Declaring steps: tuple[str, ...] fixes both at once: the contents stop being editable and the record becomes hashable. One declaration fixing both is the clue that they are one problem.

# exercise_4.py
from types import SimpleNamespace
from typing import Final

TAGS: Final[list[str]] = ["urgent", "todo"]

built = SimpleNamespace(info="Spam", tags=TAGS, note=12)
built.more = 11
print(list(vars(built)))
#: ['info', 'tags', 'note', 'more']

assigned = SimpleNamespace(info="Spam", tags=TAGS)
assigned.more = 11
assigned.note = 12
print(list(vars(assigned)))
#: ['info', 'tags', 'more', 'note']

print(vars(built) == vars(assigned), built == assigned)
#: True True

Add the attribute two ways. A keyword argument and a later assignment both add one entry to the instance’s __dict__, and vars() reads that dict. A dict keeps insertion order, and the two versions insert note at different moments. The constructor adds it to built before built.more = 11 runs, so note comes third there. In assigned the assignment to note follows assigned.more = 11, so note comes last.

Compare the contents. The order differs, but built and assigned end with the same four attributes, so the two dicts compare equal and so do the namespaces, since dict equality ignores order.

# exercise_6.py
from dataclasses import dataclass
from typing import NamedTuple

class Color(NamedTuple):
    r: int
    g: int
    b: int

class Point3(NamedTuple):
    x: int
    y: int
    z: int

print(Color(1, 2, 3) == Point3(1, 2, 3))
#: True

@dataclass(frozen=True)
class FrozenColor:
    r: int
    g: int
    b: int

print(FrozenColor(1, 2, 3) == (1, 2, 3))
#: False

Compare by position and length. Color(1, 2, 3) == Point3(1, 2, 3) is True, the same answer Dimensions gives, and for the same reason: a NamedTuple inherits tuple.__eq__, which compares length and elements and consults neither class. Adding a third NamedTuple adds a third type that compares equal to Color and Dimensions, so the family of things that equal (1, 2, 3) grows with every three-integer NamedTuple in the program. The field names are for you, not for ==.

Check the class before the fields. FrozenColor(1, 2, 3) == (1, 2, 3) is False. A frozen data class’s generated __eq__() checks other.__class__ is self.__class__ before comparing fields, and returns NotImplemented for a tuple. Python then tries the tuple’s own comparison, which also returns NotImplemented. With both sides declining, == falls back to identity, which is False for two distinct objects. A data class is not a tuple, and no tuple compares equal to one.

NamedTuple and the frozen data class offer a choice. A NamedTuple is a tuple with labels, so it interoperates with everything expecting a tuple and accepts equality with anything of the same shape. A frozen data class is a distinct type, so it refuses those comparisons and catches the mismatch instead. Which one is right depends on whether you want your three numbers to travel as data or to mean something.

The configuration bag is a SimpleNamespace. Its keys arrive at runtime, so no fixed set of fields exists to declare. A @dataclass or NamedTuple needs every field named in the class body before any instance exists, which this scenario cannot supply. SimpleNamespace accepts any name at construction or later, which is the looseness the scenario needs. The cost is a type checker that cannot catch a typo in a key name.

The grid coordinate is a NamedTuple. It must work as a dict key, so it must hash, and a NamedTuple hashes as long as its fields do. A @dataclass also hashes by value, but only when frozen (with the default eq=True), which rules out the mutable @dataclass. Between a frozen data class and a NamedTuple here, the tuple form wins on convenience: unpacking a coordinate as x, y = point and passing it to code that takes a tuple are both things the scenario needs and a frozen data class refuses.

The JSON record is a @dataclass. json.dumps() writes a NamedTuple as a bare array, so the record goes back out without its field names. Given a @dataclass, json.dumps() raises a TypeError instead of dropping the names silently. A @dataclass also has a place for the validation this scenario requires: Data Classes as Types makes __post_init__() the method that rejects a value the JSON decoder otherwise accepts unchecked. A TypedDict matches the shape JSON arrives in and names the keys for the type checker, but it is a dict at runtime and runs no code, so it cannot validate.