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'. Before the script runs, ty reports the same call as a missing-argument. 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, all from that one line.

Before you move on, name what separates your attempt from this one: a different design, a detail, or an equivalent alternative.

If you assign a longer list to the field, as in toast.steps = toast.steps + ["butter"], Python raises an AttributeError with the message can't set attribute. The type checker reports the assignment too, as color_namedtuple.py shows for red.r = 9. That attempt tests the Recipe’s immutability, which holds. The solution calls append() instead, which 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 Recipe changed, and both Python and the type checker accepted the change. NamedTuple raises an AttributeError when code rebinds toast.steps, but append() leaves toast.steps bound to the same list.

Hash the Recipe. Using the Recipe 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 Recipe has none either.

The silent append() and the TypeError have one cause. A NamedTuple freezes which object each field references, and that object stays as mutable as it was. frozen=True is shallow the same way. Declaring steps: tuple[str, ...] fixes the silent append() and the TypeError at once. The contents freeze, and the Recipe becomes hashable. One declaration fixing both is the clue that they are one problem.

Before you move on, name what separates your attempt from this one: a different design, a detail, or an equivalent alternative.

# 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__. vars() reads that dict, which keeps insertion order. The two namespaces 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. Dict equality ignores order, so the two dicts compare equal, and so do the namespaces.

Before you move on, name what separates your attempt from this one: a different design, a detail, or an equivalent alternative.

# 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 ignores both classes. Adding a third NamedTuple adds a third type that compares equal to Color and Dimensions, so the set of types whose instances equal (1, 2, 3) grows with every three-integer NamedTuple in the program. The field names serve the reader. The == operator ignores them.

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. When both sides return NotImplemented, == falls back to identity, which is False for two distinct objects.

A NamedTuple is a tuple with labels, so it works with any code that expects a tuple and compares equal to any tuple holding the same values. A frozen data class is a distinct type, so == matches it against instances of its own class and answers False for everything else. Which one is right depends on whether your three numbers should be interchangeable with any tuple of the same values.

Before you move on, name what separates your attempt from this one: a different design, a detail, or an equivalent alternative.

The configuration bag is a SimpleNamespace. Its keys arrive at runtime, so you write the code before you know the fields. A @dataclass or NamedTuple needs every field named in the class body before any instance exists. Here the names arrive with the instance. A TypedDict exists to name the keys for the type checker, but here every key arrives at runtime, after the type checker has run. SimpleNamespace accepts any name at construction or later, which is the looseness the scenario needs. The type checker cannot report a typo in a key name, because no declaration lists the keys.

The grid coordinate is a NamedTuple. It must work as a dict key, so it must hash. A NamedTuple hashes as long as its fields do. A frozen @dataclass also hashes by value (with the default eq=True). A mutable @dataclass sets __hash__ to None, so using one as a key raises a TypeError. SimpleNamespace and a TypedDict raise the same TypeError. SimpleNamespace compares by contents and defines no hash. A TypedDict is a dict at runtime.

Between a frozen data class and a NamedTuple here, the NamedTuple supports two more uses. A NamedTuple coordinate unpacks as x, y = point and passes to code that takes a tuple. Unpacking a frozen data class raises a TypeError. The type checker rejects a frozen data class passed to a parameter that declares a tuple.

The JSON record is a frozen data class. json.dumps() writes a NamedTuple as a bare array that holds the values and drops the 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 place to check each value the JSON decoder produces. Freezing the data class makes that check final, since every field keeps the value __post_init__() checked. Python raises an AttributeError at class creation if a NamedTuple class defines __new__() or __init__(), so a NamedTuple runs its check in a factory function that a caller can bypass. A TypedDict describes the dict that json.loads() returns and names the keys for the type checker, but at runtime it is a dict, which stores whatever values json.loads() gives it. A SimpleNamespace accepts any name with any value, at runtime and under the type checker, so the record holds whatever the JSON held.

Before you move on, name what separates your attempt from this one: a different design, a detail, or an equivalent alternative.