{"title":"Dunder (Magic) Methods","description":"","content":"Dunder methods are the hooks Python uses to make your own classes behave like built-in types. The name is short for \"double underscore\", because each method begins and ends with two underscores (`__init__`, `__len__`, `__repr__`). Writing the right dunder method on a class is what lets `len(cart)` work on your `Cart`, `print(order)` produce a readable string, or `product in wishlist` answer the right question. This chapter walks through the dunder methods you'll reach for most often.\n\n---\n\n# What a Dunder Method Actually Does\n\nWhen you write `len(cart)`, Python doesn't know in advance what \"length\" means for your `Cart` class. It can't, because `Cart` is something you defined. So Python uses a simple rule: take the call `len(cart)` and rewrite it as `cart.__len__()`. If that method exists on the object, the call succeeds. If it doesn't, Python raises `TypeError`.\n\nEvery built-in operation in Python works this way. `print(order)` calls `order.__str__()`. `item in cart` calls `cart.__contains__(item)`. `wishlist[0]` calls `wishlist.__getitem__(0)`. The language doesn't have a privileged list of types that get to use these operations. Any class that defines the right dunder method gets to play.\n\n\n```python\nclass Cart:\n def __init__(self, items):\n self.items = items\n\n def __len__(self):\n return len(self.items)\n\ncart = Cart([\"mouse\", \"keyboard\", \"cable\"])\nprint(len(cart))\n```\n\n\nThe call `len(cart)` triggers Python's lookup of `__len__` on the `Cart` instance. It finds the method, calls it with no arguments (the instance itself is `self`), and uses whatever the method returns. The result is `3`, exactly as if `cart` were a built-in list.\n\nThis dispatch is what the rest of the chapter is about. Pick the operation you want your class to support, find the dunder method that backs it, and define it. The interpreter takes care of the rest.\n\n\n```mermaid\nflowchart LR\n Call[\"len(cart)\"]:::cyan\n Lookup[\"Python looks for
cart.__len__\"]:::orange\n Found{\"method exists?\"}:::orange\n Invoke[\"call cart.__len__()\"]:::green\n Result[\"return the value\"]:::green\n Error[\"raise TypeError:
object has no len()\"]:::red\n\n Call --> Lookup --> Found\n Found -->|yes| Invoke --> Result\n Found -->|no| Error\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram shows the two paths Python takes when you call a built-in like `len()` on a custom object. The cyan node is the user-facing call, the orange nodes show the lookup, and the result is either a successful dispatch (green) or a `TypeError` (red). Every dunder-backed operation in the chapter follows this shape: a friendly syntax on the outside, a method lookup on the inside.\n\n---\n\n# `__str__` vs `__repr__`: Two Strings, Two Audiences\n\nAlmost every object you print in Python ends up going through one of two dunder methods: `__str__` or `__repr__`. They both turn an object into a string, but they serve different audiences. `__str__` is for end users; `__repr__` is for developers.\n\n`print(obj)` calls `obj.__str__()`. The REPL, when it echoes a value, calls `repr(obj)` which calls `obj.__repr__()`. The `repr()` builtin is also what `print` uses on objects inside a list or dict, which is why `[Order(1)]` shows up with the bracket-y form even when you just `print` the list.\n\n\n```python\nclass Order:\n def __init__(self, order_id, total):\n self.order_id = order_id\n self.total = total\n\norder = Order(101, 59.99)\nprint(order)\nprint(repr(order))\n```\n\n\nNeither output is useful. Without a `__str__` or `__repr__` on the class, Python falls back to the default: the class name and the memory address. Define `__repr__` and `__str__` and the output snaps into shape.\n\n\n```python\nclass Order:\n def __init__(self, order_id, total):\n self.order_id = order_id\n self.total = total\n\n def __repr__(self):\n return f\"Order(order_id={self.order_id!r}, total={self.total!r})\"\n\n def __str__(self):\n return f\"Order #{self.order_id}: ${self.total:.2f}\"\n\norder = Order(101, 59.99)\nprint(order) # uses __str__\nprint(repr(order)) # uses __repr__\nprint([order]) # list uses __repr__ for elements\n```\n\n\nThe `__str__` form is what you'd put on a receipt or in a log line meant for humans. The `__repr__` form looks like the call that would re-create the object, which is exactly what the convention asks for. The official rule of thumb from the Python docs: `__repr__` should be unambiguous, and ideally a string that, if you typed it into the REPL, would give you back an equal object.\n\nHere's the trick that saves work most of the time: **define `__repr__` first**. If a class has a `__repr__` but no `__str__`, Python uses `__repr__` for both. So a single well-written `__repr__` covers prints, lists, dicts, error messages, and debugger output all at once. Only define `__str__` separately when you genuinely need a different presentation for end users.\n\n\n> **INFO**\n>\n> **Cost:** `repr()` is what shows up in tracebacks. A class with no `__repr__` makes every error message harder to read because you're looking at `<__main__.Order object at 0x10455a700>` instead of `Order(order_id=101, total=59.99)`. Adding `__repr__` is cheap and pays back every time the code breaks.\n\n\n\n| Method | Called by | Audience | Goal |\n| --- | --- | --- | --- |\n| `__repr__` | `repr(obj)`, REPL echo, `print([obj])`, tracebacks | Developers | Unambiguous, debug-friendly, ideally re-creatable |\n| `__str__` | `print(obj)`, `str(obj)`, f-strings with `{obj}` | End users | Readable, presentation-style |\n\n\n---\n\n# `__len__`: Making `len(obj)` Work\n\n`__len__` is the dunder that powers the `len()` builtin. Any class that represents a collection of things should define it. A `Cart` has a number of items, a `Wishlist` has a number of products, a `Catalog` has a number of entries: each of those is a natural candidate.\n\n\n```python\nclass Cart:\n def __init__(self):\n self.items = []\n\n def add(self, item):\n self.items.append(item)\n\n def __len__(self):\n return len(self.items)\n\ncart = Cart()\ncart.add(\"mouse\")\ncart.add(\"keyboard\")\ncart.add(\"hdmi cable\")\n\nprint(len(cart))\n```\n\n\nThe method must return a non-negative integer. Returning a float, a negative number, or a non-numeric value raises `TypeError` when `len()` is called. Python enforces this for a reason: a length is a count, and counts don't go negative or fractional.\n\n`__len__` also affects truthiness. If a class defines `__len__` but no `__bool__`, then `bool(obj)` returns `False` when the length is zero and `True` otherwise. That matches the way built-in containers behave (`bool([])` is `False`, `bool([1])` is `True`), and it usually does the right thing for free.\n\n---\n\n# `__bool__`: What Truthy Looks Like for Your Class\n\nEvery Python object can be tested in an `if` statement. The rule Python uses is simple but layered:\n\n1. If the object defines `__bool__`, call it and use what it returns.\n2. Otherwise, if the object defines `__len__`, the object is truthy when the length is nonzero.\n3. Otherwise, the object is truthy.\n\nThat third rule is why a fresh class with no special methods is always truthy. An `Order` object with all-zero fields is still truthy unless you tell Python otherwise.\n\n\n```python\nclass Cart:\n def __init__(self):\n self.items = []\n\nempty = Cart()\n\nif empty:\n print(\"cart has items\")\nelse:\n print(\"cart is empty\")\n```\n\n\nThat's almost certainly the wrong answer for an empty cart. Two ways to fix it. The first is to add `__len__`, which gives you truthiness as a free side effect:\n\n\n```python\nclass Cart:\n def __init__(self):\n self.items = []\n\n def __len__(self):\n return len(self.items)\n\nempty = Cart()\n\nif empty:\n print(\"cart has items\")\nelse:\n print(\"cart is empty\")\n```\n\n\nThe second is to define `__bool__` explicitly, which is the right call when \"truthiness\" doesn't line up with \"has elements\". An `Order` is truthy when it's been placed, regardless of how many items are in it:\n\n\n```python\nclass Order:\n def __init__(self, order_id):\n self.order_id = order_id\n self.placed = False\n\n def __bool__(self):\n return self.placed\n\norder = Order(101)\nprint(bool(order))\norder.placed = True\nprint(bool(order))\n```\n\n\n`__bool__` must return a `bool`. Returning `0` or `1` works in practice because of Python's leniency, but the convention is to return `True` or `False` directly.\n\n\n> **INFO**\n>\n> **Cost:** If both `__bool__` and `__len__` are defined, `__bool__` wins. That means a class that defines `__bool__` based on a different field can drift out of sync with `len()`. Pick one mental model and stick with it.\n\n\n---\n\n# `__contains__`: Making `in` Work\n\nThe `in` operator is sugar for `__contains__`. `item in cart` becomes `cart.__contains__(item)`. If the method isn't defined, Python falls back to iterating the object and comparing each element with `==`, which is slow but at least makes `in` work as long as the object is iterable.\n\n\n```python\nclass Cart:\n def __init__(self):\n self.items = []\n\n def add(self, item):\n self.items.append(item)\n\n def __contains__(self, item):\n return item in self.items\n\ncart = Cart()\ncart.add(\"mouse\")\ncart.add(\"keyboard\")\n\nprint(\"mouse\" in cart)\nprint(\"monitor\" in cart)\n```\n\n\nThe advantage of defining `__contains__` is that you control the comparison. Maybe membership in your `Catalog` is checked by product ID, not by object equality. Maybe a customer counts as being \"in\" a region if their address matches a prefix. Defining `__contains__` lets you express that directly:\n\n\n```python\nclass Catalog:\n def __init__(self, products):\n # products is a dict of {product_id: name}\n self.products = products\n\n def __contains__(self, product_id):\n return product_id in self.products\n\ncatalog = Catalog({101: \"mouse\", 102: \"keyboard\", 103: \"hdmi cable\"})\nprint(101 in catalog)\nprint(999 in catalog)\n```\n\n\n`__contains__` should return a `bool`. Python coerces the return value to a bool anyway, so returning a truthy or falsy value works, but returning `True` or `False` is cleaner and easier to read.\n\n\n> **INFO**\n>\n> **Cost:** Without `__contains__`, `x in obj` falls back to iterating the whole object and comparing every element. For a `Cart` of three items that's fine. For a `Catalog` of 100,000 products backed by a dict, iterating means O(n) instead of O(1). Defining `__contains__` to delegate to the underlying dict keeps the lookup fast.\n\n\n---\n\n# Subscripting: `__getitem__`, `__setitem__`, `__delitem__`\n\nThe square bracket syntax (`cart[0]`, `cart[0] = \"mouse\"`, `del cart[0]`) is backed by three dunder methods. Define them and your class behaves like a list or dict from the outside.\n\n\n| Syntax | Method called |\n| --- | --- |\n| `cart[key]` | `cart.__getitem__(key)` |\n| `cart[key] = value` | `cart.__setitem__(key, value)` |\n| `del cart[key]` | `cart.__delitem__(key)` |\n\n\nThe `key` can be anything: an integer (list-like), a string (dict-like), a slice, a tuple. Your method decides what to do with it.\n\n\n```python\nclass Cart:\n def __init__(self):\n self.items = []\n\n def add(self, item):\n self.items.append(item)\n\n def __getitem__(self, index):\n return self.items[index]\n\n def __setitem__(self, index, value):\n self.items[index] = value\n\n def __delitem__(self, index):\n del self.items[index]\n\n def __len__(self):\n return len(self.items)\n\ncart = Cart()\ncart.add(\"mouse\")\ncart.add(\"keyboard\")\ncart.add(\"hdmi cable\")\n\nprint(cart[0]) # __getitem__\ncart[1] = \"monitor\" # __setitem__\nprint(cart[1])\ndel cart[2] # __delitem__\nprint(len(cart))\n```\n\n\nA class that defines `__getitem__` also gets a free fallback for iteration. If `__iter__` isn't defined, Python iterates the object by calling `__getitem__(0)`, `__getitem__(1)`, and so on until it sees an `IndexError`. This is a legacy mechanism, but it's still in the language, and it's why some old code skips `__iter__` entirely on list-like classes.\n\nSlicing also works through `__getitem__`. When you write `cart[1:3]`, Python passes a `slice` object as the index, and the method has to handle it. The simplest way is to delegate to the underlying list:\n\n\n```python\nclass Cart:\n def __init__(self, items):\n self.items = list(items)\n\n def __getitem__(self, index):\n # works for both single index and slice\n return self.items[index]\n\ncart = Cart([\"mouse\", \"keyboard\", \"cable\", \"monitor\"])\nprint(cart[1])\nprint(cart[1:3])\n```\n\n\nThe list's `__getitem__` already knows how to handle integers and slices, so delegating to it is the cleanest approach. Hand-rolling slice support is mostly an exercise; for real code, delegate.\n\n---\n\n# Iteration: `__iter__` and `__next__` (Brief)\n\nThe modern way to make a class iterable is to define `__iter__`. The method must return an **iterator**, which is any object with a `__next__` method. Each call to `__next__` returns the next value or raises `StopIteration` when there are no more.\n\n\n```python\nclass Cart:\n def __init__(self, items):\n self.items = items\n\n def __iter__(self):\n return iter(self.items)\n\ncart = Cart([\"mouse\", \"keyboard\", \"cable\"])\nfor item in cart:\n print(item)\n```\n\n\nThat's the easy case: delegate to the underlying list's iterator. The harder case is when you want to write the iterator yourself, with `__next__` and `StopIteration`. The headline: `__iter__` returns an iterator, `__next__` advances it, `StopIteration` ends it.\n\n---\n\n# `__call__`: Making Objects Callable\n\nPython makes a hard distinction between \"function\" and \"object\" in most languages, but not in Python. Any object can be made callable by defining `__call__`. Once defined, the object can be invoked with parentheses just like a function.\n\n\n```python\nclass DiscountCalculator:\n def __init__(self, percent_off):\n self.percent_off = percent_off\n\n def __call__(self, price):\n return price * (1 - self.percent_off / 100)\n\nten_percent = DiscountCalculator(10)\nblack_friday = DiscountCalculator(40)\n\nprint(ten_percent(49.99))\nprint(black_friday(49.99))\n```\n\n\n`ten_percent` and `black_friday` look like functions when you call them, but they're instances of `DiscountCalculator`. Each one carries its own state (`self.percent_off`), and that state is part of every call. This is a clean way to build configurable \"function-like\" objects: decorators, validators, predicates, anything that needs to remember settings across calls.\n\nFunctions in Python are themselves callable because they have `__call__`. That's not a metaphor; you can literally inspect it:\n\n\n```python\ndef greet(name):\n return f\"Hello, {name}\"\n\nprint(callable(greet))\nprint(hasattr(greet, \"__call__\"))\n```\n\n\nThe `callable()` builtin returns `True` for anything with `__call__`, which is why functions, methods, classes, and `__call__`-defining objects all pass the same test.\n\n---\n\n# `__eq__` and `__hash__`: The Contract You Must Not Break\n\nThis section matters more than it looks. Getting `__eq__` wrong gives you confusing equality. Getting `__hash__` wrong, or forgetting it, breaks sets and dicts in subtle ways that don't blow up immediately but corrupt your program's logic.\n\nThe default `__eq__` compares object identity: two objects are equal only if they are literally the same object in memory. That's almost never what you want for value-like classes.\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\na = Product(101, \"mouse\")\nb = Product(101, \"mouse\")\n\nprint(a == b)\n```\n\n\nTwo distinct `Product` instances with identical fields aren't equal because Python's default `__eq__` is \"are these the same object?\". Override `__eq__` to compare by value:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\n def __eq__(self, other):\n if not isinstance(other, Product):\n return NotImplemented\n return self.product_id == other.product_id\n\na = Product(101, \"mouse\")\nb = Product(101, \"mouse\")\nc = Product(102, \"keyboard\")\n\nprint(a == b)\nprint(a == c)\n```\n\n\nTwo things in that `__eq__`:\n\n1. The `isinstance` check protects against comparing apples to oranges. Returning `NotImplemented` (not `False`) tells Python \"I don't know how to compare these\"; Python then tries the other object's `__eq__`. Returning `False` would mask a real mismatch.\n2. Equality is defined by `product_id`, not by all the fields. That's a deliberate choice: a product is \"the same product\" if it has the same ID, even if the name changes.\n\nHere's where it gets serious. Python's data model has a rule: **if you override `__eq__`, you must also override `__hash__`, or the class becomes unhashable.** When you define `__eq__` without `__hash__`, Python automatically sets `__hash__` to `None`, which makes the object unhashable, which means it can't go in a set or be used as a dict key.\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\n def __eq__(self, other):\n if not isinstance(other, Product):\n return NotImplemented\n return self.product_id == other.product_id\n\np = Product(101, \"mouse\")\nwishlist = set()\nwishlist.add(p)\n```\n\n\nThat's the failure. Python turned off hashing because you redefined equality and didn't tell it how to hash. The fix is to add `__hash__`:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\n def __eq__(self, other):\n if not isinstance(other, Product):\n return NotImplemented\n return self.product_id == other.product_id\n\n def __hash__(self):\n return hash(self.product_id)\n\na = Product(101, \"mouse\")\nb = Product(101, \"mouse\")\nc = Product(102, \"keyboard\")\n\nwishlist = {a, b, c}\nprint(len(wishlist))\nprint(a in wishlist)\n```\n\n\nThe set contains two products, not three, because `a` and `b` compare equal and hash to the same value. The set treats them as one entry. That's the whole point of the contract.\n\nThe rule, stated formally: **if `a == b`, then `hash(a) == hash(b)`.** The reverse isn't required (two unequal objects can share a hash, that's just a collision). But equal objects sharing a hash is mandatory, because hash sets and dicts use the hash to find the bucket, then `==` to confirm a match. If equal objects hashed differently, the dict would miss its own keys.\n\nTwo practical rules to remember:\n\n\n| If you override... | You must also... | Why |\n| --- | --- | --- |\n| `__eq__` | Define `__hash__` (or accept the class becomes unhashable) | Python sets `__hash__` to `None` automatically when you override `__eq__` |\n| `__hash__` | Make sure it agrees with `__eq__` | Equal objects must hash equal, or sets and dicts will lose entries |\n\n\nAnd one more practical rule: **`__hash__` must be based on immutable state.** If you hash by an attribute that can change after the object is in a set, the set silently loses the object. The hash put it in one bucket, the mutated value points to a different bucket, and lookups go to the new bucket and find nothing.\n\n\n```python\n# What's wrong with this code?\n\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\n def __eq__(self, other):\n return isinstance(other, Product) and self.name == other.name\n\n def __hash__(self):\n return hash(self.name)\n\np = Product(101, \"mouse\")\nwishlist = {p}\np.name = \"monitor\"\nprint(p in wishlist)\n```\n\n\nThe product is in the set, but `in` reports `False`. The hash at insert time was computed from `\"mouse\"`. After mutation, `hash(p)` is computed from `\"monitor\"`, which points to a different bucket. The set still has the object physically, but its lookup machinery can't find it. The fix is to hash on something that doesn't change (a stable ID), and to either freeze the class (don't allow mutation) or hash on an immutable subset of fields.\n\n---\n\n# Object Lifecycle: `__init__`, `__new__`, `__del__`\n\n`__init__` is the dunder you've already seen on every class: it runs after the object is created, and its job is to set up the instance's state. It's not technically a constructor; it's an initializer. The actual constructor is `__new__`, which runs first and is responsible for creating the object.\n\nFor 99% of classes, you only ever define `__init__`. `__new__` exists in the background, doing its default job: allocate the instance, then hand it to `__init__`. The rare cases where you override `__new__` are when you need to customize creation itself: enforcing a singleton, returning a cached instance, subclassing an immutable type like `tuple` or `str`.\n\n\n```python\nclass Product:\n def __new__(cls, *args, **kwargs):\n print(f\"__new__ called for {cls.__name__}\")\n return super().__new__(cls)\n\n def __init__(self, product_id, name):\n print(f\"__init__ called with {product_id}, {name}\")\n self.product_id = product_id\n self.name = name\n\np = Product(101, \"mouse\")\n```\n\n\n`__new__` runs first, creates the instance, and returns it. Python then calls `__init__` on that instance to populate it. In day-to-day code, you'll define `__init__` and never touch `__new__`. `__new__` is mainly needed for advanced patterns like immutable subclasses and metaclasses.\n\n`__del__` is the destructor: Python calls it when the object is about to be garbage-collected. In practice, this is the worst place to put cleanup logic. The exact timing of when an object is collected isn't guaranteed, and `__del__` can be skipped entirely if the interpreter exits with the object still alive. The Pythonic way to handle resource cleanup is the context manager protocol (`__enter__` / `__exit__`).\n\n\n```python\nclass Order:\n def __init__(self, order_id):\n self.order_id = order_id\n print(f\"order {self.order_id} created\")\n\n def __del__(self):\n print(f\"order {self.order_id} being collected\")\n\ndef make_order():\n o = Order(101)\n\nmake_order()\nprint(\"after function\")\n```\n\n\nThat output looks tidy because CPython uses reference counting, which collects the object the moment its last reference disappears. On other Python implementations (PyPy, Jython), garbage collection runs less predictably, and `__del__` might fire much later or not at all. Don't rely on it for anything important.\n\n---\n\n# Reference Table of Common Dunder Methods\n\nHere's the consolidated reference for the methods covered in this chapter. The full data-model docs list dozens more; these are the ones you'll reach for first.\n\n\n| Dunder | Triggered by | Typical use |\n| --- | --- | --- |\n| `__init__(self, ...)` | Object creation | Initialize instance state |\n| `__new__(cls, ...)` | Object creation (before `__init__`) | Customize object creation (rare) |\n| `__del__(self)` | Garbage collection | Cleanup (use context managers instead) |\n| `__repr__(self)` | `repr(obj)`, REPL echo, lists/dicts | Unambiguous developer-facing string |\n| `__str__(self)` | `print(obj)`, `str(obj)`, f-strings | Readable user-facing string |\n| `__len__(self)` | `len(obj)` | Return count of items |\n| `__bool__(self)` | `bool(obj)`, `if obj:` | Define truthiness |\n| `__contains__(self, item)` | `item in obj` | Membership test |\n| `__getitem__(self, key)` | `obj[key]` | Subscript access (also enables old-style iteration) |\n| `__setitem__(self, key, value)` | `obj[key] = value` | Subscript assignment |\n| `__delitem__(self, key)` | `del obj[key]` | Subscript deletion |\n| `__iter__(self)` | `iter(obj)`, `for x in obj` | Return an iterator |\n| `__next__(self)` | `next(iterator)` | Return next value or raise `StopIteration` |\n| `__call__(self, ...)` | `obj(...)` | Make instance callable |\n| `__eq__(self, other)` | `obj == other` | Value equality (must pair with `__hash__`) |\n| `__hash__(self)` | `hash(obj)`, sets, dict keys | Return integer hash; must agree with `__eq__` |\n\n\nThe dunders for arithmetic (`__add__`, `__sub__`, `__mul__`), ordering (`__lt__`, `__le__`, `__gt__`, `__ge__`), context management (`__enter__`, `__exit__`), and attribute access (`__getattr__`, `__setattr__`) are covered separately.\n\n---\n\n# Putting It Together: A Cart That Behaves Like a Built-In\n\nHere's a single `Cart` class that uses these dunder methods together. It can be printed, measured with `len()`, tested with `in`, subscripted, iterated, called, and compared.\n\n\n```python\nclass Cart:\n def __init__(self, customer_id):\n self.customer_id = customer_id\n self.items = []\n\n def add(self, item):\n self.items.append(item)\n\n def __repr__(self):\n return f\"Cart(customer_id={self.customer_id!r}, items={self.items!r})\"\n\n def __str__(self):\n return f\"Cart for customer {self.customer_id} ({len(self)} items)\"\n\n def __len__(self):\n return len(self.items)\n\n def __bool__(self):\n return len(self.items) > 0\n\n def __contains__(self, item):\n return item in self.items\n\n def __getitem__(self, index):\n return self.items[index]\n\n def __iter__(self):\n return iter(self.items)\n\n def __eq__(self, other):\n if not isinstance(other, Cart):\n return NotImplemented\n return self.customer_id == other.customer_id and self.items == other.items\n\n def __hash__(self):\n return hash((self.customer_id, tuple(self.items)))\n\ncart = Cart(customer_id=1)\ncart.add(\"mouse\")\ncart.add(\"keyboard\")\ncart.add(\"hdmi cable\")\n\nprint(cart)\nprint(repr(cart))\nprint(len(cart))\nprint(bool(cart))\nprint(\"mouse\" in cart)\nprint(cart[0])\nfor item in cart:\n print(f\"- {item}\")\n```\n\n\nEvery line of that output is a different dunder method firing. None of the calls are special syntax for `Cart`; they're the same `len`, `print`, `in`, and indexing you'd use on a list. That's the whole point of the data model: define the right methods and the language treats your class like one of its built-ins.","pageType":"python"}

Dunder (Magic) Methods

Get Premium