{"title":"Instance Attributes","description":"","content":"An instance attribute is a piece of data attached to one specific object, not to the class as a whole. Writing `self.name = name` inside `__init__` creates an instance attribute on the new object: it lives on that one instance, and other instances of the same class have their own separate copies. This lesson covers how instance attributes are stored, how to read, set, and delete them, the tools Python provides for inspecting them, and the small set of pitfalls that show up when classes carry state.\n\n---\n\n# Where Instance Attributes Live\n\nEvery regular Python instance carries a hidden dictionary called `__dict__`. Writing `self.price = 29.99` adds the key `\"price\"` with the value `29.99` to that dictionary. Reading `instance.price` later looks the key up. The dot in `instance.price` is shorthand for a dictionary lookup with a few extra rules.\n\nA class small enough to see the storage directly:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.__dict__)\n```\n\n\nTwo attributes, two keys in the dict. Every assignment to `self.something` inside the constructor (or anywhere else) writes into that dict. Reading `mouse.name` is roughly `mouse.__dict__[\"name\"]` plus the extra lookup machinery Python uses to fall back to the class when an attribute isn't on the instance.\n\nThe point of `__dict__` is that **each instance has its own**. Two `Product` objects have two separate `__dict__` dictionaries, so writing to one doesn't show up in the other:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nkeyboard = Product(\"Mechanical Keyboard\", 89.99)\n\nprint(mouse.__dict__)\nprint(keyboard.__dict__)\nprint(mouse.__dict__ is keyboard.__dict__)\n```\n\n\nTwo instances, two `__dict__` dictionaries, two separate copies of the attribute storage. This is what makes object-oriented code work: each instance carries its own state, isolated from every other instance of the same class.\n\nMost Python classes have `__dict__`, but not all. Classes that define `__slots__` use a more compact storage that's faster and uses less memory but doesn't allow arbitrary new attributes after construction. `__slots__` is covered at the end of this lesson; for most Python code, assume `__dict__` is present.\n\n---\n\n# Setting Instance Attributes Inside `__init__`\n\nThe standard place to set instance attributes is inside `__init__`. The constructor receives the values from the caller and writes them onto the new instance. The reason this is the standard pattern is worth spelling out.\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock):\n self.name = name\n self.price = price\n self.stock = stock\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nprint(mouse.name, mouse.price, mouse.stock)\n```\n\n\nPutting the attribute setup in `__init__` has two practical benefits. First, every instance starts life with the same shape: every `Product` has a `name`, a `price`, and a `stock`. Code that uses `Product` instances doesn't have to defensively check whether each attribute exists, because the constructor guarantees they do. Second, the `__init__` body is the canonical place to look up \"what attributes does this class carry?\" A future reader opens the class, reads the constructor, and learns the shape of the data.\n\nAttributes can also be computed inside `__init__` rather than just stored from parameters:\n\n\n```python\nclass Cart:\n def __init__(self, items, tax_rate):\n self.items = items\n self.tax_rate = tax_rate\n self.subtotal = sum(items)\n self.total = self.subtotal * (1 + tax_rate)\n\ncart = Cart([29.99, 14.99, 9.99], 0.08)\nprint(f\"Items: {cart.items}\")\nprint(f\"Subtotal: ${cart.subtotal:.2f}\")\nprint(f\"Total: ${cart.total:.2f}\")\n```\n\n\n`subtotal` and `total` aren't constructor parameters; they're derived from `items` and `tax_rate` inside the body. The caller doesn't compute them, and the values are then available as plain attributes on the instance. The trade-off is that they're a snapshot from construction time: if the caller mutates `cart.items` later, `cart.subtotal` won't update on its own. Keeping derived values in sync with their sources is what `@property` is for.\n\n---\n\n# Setting Attributes Outside `__init__`\n\nPython is permissive about attribute creation. Attributes can be added to an instance from outside the class, after construction, by assigning to a name through the dot:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nmouse.category = \"peripherals\"\nmouse.tags = [\"wireless\", \"ergonomic\"]\n\nprint(mouse.__dict__)\n```\n\n\nAfter the assignments, `mouse` has four attributes. `category` and `tags` weren't mentioned in `__init__`, but the assignment created them anyway. This dynamic behavior is sometimes useful (decorating an instance with extra data for a specific use case, attaching debug info) but it's discouraged for the everyday case of \"this class has these attributes\". The problem is that the shape of the data becomes inconsistent: some `Product` instances have a `category` and some don't, depending on whether one was set after construction. Code that reads `product.category` has to handle the missing case.\n\nThe conventional rule: **declare all the attributes a class carries in `__init__`**, even if they start as `None` or `0` or an empty list. That way every instance has the same shape, and the missing-attribute case never arises.\n\n\n```python\nclass Product:\n def __init__(self, name, price, category=None, tags=None):\n self.name = name\n self.price = price\n self.category = category\n self.tags = tags if tags is not None else []\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.__dict__)\n```\n\n\nNow every `Product` has all four attributes from the moment it's created, even when the caller omits `category` and `tags`. The shape is consistent, and reading `mouse.category` always returns something (possibly `None`), never raises.\n\nSetting new attributes from outside the class is fine for quick experiments at the REPL or for one-off scripts. For code that will be revisited, keep the attribute set inside `__init__`.\n\n---\n\n# Reading and Mutating Instance Attributes\n\nReading an attribute uses the same dot syntax as setting one. Python looks the name up, returns the value, and the surrounding code uses it.\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock):\n self.name = name\n self.price = price\n self.stock = stock\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\n\nprint(mouse.name)\nprint(mouse.price * 1.08)\nprint(f\"{mouse.stock} units in stock\")\n```\n\n\nEach read goes through the same lookup. The attribute names work in any context that accepts a value: f-strings, arithmetic, comparisons, function arguments.\n\nMutating an attribute means assigning a new value to the same name. The previous value is replaced:\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock):\n self.name = name\n self.price = price\n self.stock = stock\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nprint(f\"Before: ${mouse.price}\")\n\nmouse.price = 24.99\nprint(f\"After: ${mouse.price}\")\n```\n\n\nThe assignment `mouse.price = 24.99` updates the `\"price\"` key in `mouse.__dict__`. There's nothing special about modifying an attribute after construction; it's the same operation as the initial assignment in `__init__`. The choice of when to allow mutation is a design question, not a language one. Some classes treat their attributes as fixed once `__init__` finishes (immutable-style); others mutate freely. Python doesn't enforce either, but conventions like `@property` and `@dataclass(frozen=True)` exist for stricter rules.\n\nMethods that mutate state typically read and write attributes through `self`:\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock):\n self.name = name\n self.price = price\n self.stock = stock\n\n def restock(self, quantity):\n self.stock = self.stock + quantity\n\n def sell(self, quantity):\n if quantity > self.stock:\n raise ValueError(f\"only {self.stock} in stock, asked for {quantity}\")\n self.stock = self.stock - quantity\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nmouse.restock(20)\nmouse.sell(15)\nprint(f\"{mouse.name}: {mouse.stock} in stock\")\n```\n\n\n`restock` reads `self.stock`, adds the quantity, and writes the result back. `sell` does the inverse with a validation check. Both work on whichever instance they were called on, because `self` is that instance.\n\n---\n\n# Deleting Instance Attributes\n\nAn attribute can be removed from an instance with `del`. After deletion, reading the attribute raises `AttributeError` (or falls back to the class, if a class attribute with the same name exists).\n\n\n```python\nclass Product:\n def __init__(self, name, price, category):\n self.name = name\n self.price = price\n self.category = category\n\nmouse = Product(\"Wireless Mouse\", 29.99, \"peripherals\")\nprint(mouse.__dict__)\n\ndel mouse.category\nprint(mouse.__dict__)\n\ntry:\n print(mouse.category)\nexcept AttributeError as e:\n print(f\"raised: {e}\")\n```\n\n\nThe `del` statement removes the `\"category\"` key from `mouse.__dict__`. Reading `mouse.category` afterwards fails because the key is gone, and there's no class-level `category` attribute to fall back to.\n\nDeleting attributes is rare in everyday code. It comes up occasionally when an attribute should only exist during a specific phase of an object's life (a temporary cache to clear, or a one-time setup value), but for normal classes, attributes are set in `__init__` and left there, possibly with their values mutated. Use `del obj.attr` only when there's a real reason to remove the attribute entirely rather than reset it.\n\n---\n\n# Inspecting Instance Attributes\n\nPython provides a few tools to ask \"what attributes does this instance carry?\" The most direct is `__dict__`, which returns the storage dictionary itself:\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock):\n self.name = name\n self.price = price\n self.stock = stock\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nprint(mouse.__dict__)\n```\n\n\n`vars(obj)` is the same thing through a built-in function:\n\n\n```python\nprint(vars(mouse))\n```\n\n\n`vars(obj)` and `obj.__dict__` return the same dict. The function form is sometimes a little clearer in code that uses it programmatically, and it works on modules too (`vars(some_module)` returns the module's globals). For inspecting an instance, both are interchangeable.\n\n`dir(obj)` returns a longer list of names, including methods inherited from the class and `object`:\n\n\n```python\nprint([name for name in dir(mouse) if not name.startswith(\"_\")])\n```\n\n\n`dir(obj)` lists everything accessible through the dot, including methods. The filter above strips out the dunder-prefixed names (like `__init__`, `__class__`, `__repr__`) so only the user-defined names appear. For \"what attributes does this specific instance carry?\", use `vars(obj)` or `obj.__dict__`. For \"what can be done with this object, including inherited methods?\", use `dir(obj)`.\n\nA single attribute can also be checked with `hasattr` and read with a default through `getattr`:\n\n\n```python\nprint(hasattr(mouse, \"name\"))\nprint(hasattr(mouse, \"discount\"))\n\nprint(getattr(mouse, \"name\"))\nprint(getattr(mouse, \"discount\", 0))\n```\n\n\n`hasattr(obj, \"attr\")` returns `True` if the attribute exists (on the instance or its class). `getattr(obj, \"attr\")` returns the value, and `getattr(obj, \"attr\", default)` returns the default when the attribute is missing instead of raising. These pair well in code that handles optional attributes without throwing.\n\n`hasattr` is implemented by trying `getattr` and catching `AttributeError`. For attributes that exist, it's fast. For ones that don't, it pays the cost of raising and catching an exception. In tight loops, comparing against a known set or using `getattr(obj, \"attr\", None)` is usually cheaper than two separate `hasattr` plus `getattr` calls.\n\n---\n\n# How Lookup Sees the Instance Dict\n\nWhen `mouse.name` is read, Python doesn't go straight to `mouse.__dict__[\"name\"]`. It runs through a lookup procedure that checks several places before giving up. Knowing the order helps make sense of behavior that otherwise looks strange. The simplified version is:\n\n1. Check the instance's `__dict__` for the name.\n2. If not found, check the class's `__dict__` (and its base classes).\n3. If still not found, raise `AttributeError`.\n\nFor purely instance attributes (the ones set with `self.x = ...`), step 1 finds them and the lookup stops:\n\n\n```mermaid\nflowchart LR\n Read[\"mouse.name\"]:::cyan\n InstDict[\"mouse.__dict__
{'name': 'Mouse',
'price': 29.99}\"]:::orange\n Found[\"return 'Mouse'\"]:::green\n\n Read --> InstDict --> Found\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```\n\n\nThe diagram shows the simple path: a read for an attribute that lives on the instance finds it in step 1 and returns immediately. The instance's storage is checked first, and the class isn't consulted unless the instance doesn't have the name.\n\nThe same lookup applies to writes, but with one important difference: **writes always go to the instance**. `mouse.name = \"Updated\"` writes to `mouse.__dict__[\"name\"]`, never to the class. This is why mutating an attribute on one instance doesn't affect any other instance: each instance has its own `__dict__`, and writes never reach across.\n\nThis split (reads check both instance and class, writes only touch the instance) is the source of one of the common pitfalls with classes, the shared-mutable-class-attribute trap. The key point is that the asymmetry exists.\n\n---\n\n# Dynamic Attribute Creation\n\nPython's permissiveness about adding attributes after the fact has one occasionally useful corollary: an instance's attributes can be built from a dictionary or a sequence of pairs at runtime.\n\n\n```python\nclass Product:\n def __init__(self, **kwargs):\n for key, value in kwargs.items():\n setattr(self, key, value)\n\nmouse = Product(name=\"Wireless Mouse\", price=29.99, stock=50, category=\"peripherals\")\nprint(mouse.__dict__)\n```\n\n\n`setattr(obj, \"name\", value)` is the function form of `obj.name = value`. The pair (`setattr` and `getattr`) reads and writes attributes when the attribute name is itself a variable. This pattern shows up in code that builds objects from external data (rows from a CSV, fields from a JSON payload) without writing each attribute by hand.\n\nThe drawback is the same as setting attributes outside `__init__`: the shape of the object isn't documented anywhere. A future reader doesn't know what attributes a `Product` carries without running the program. For everyday classes, declare the attributes explicitly in `__init__`. For genuine \"building an object from a dynamic schema\" cases, the `**kwargs` plus `setattr` pattern fits.\n\nA more structured alternative for the same use case is `types.SimpleNamespace`, a built-in throwaway class designed for dot-accessible attribute bags:\n\n\n```python\nfrom types import SimpleNamespace\n\nmouse = SimpleNamespace(name=\"Wireless Mouse\", price=29.99, stock=50)\nprint(mouse)\nprint(mouse.name)\n```\n\n\n`SimpleNamespace` is \"an object whose attributes are whatever the constructor receives, with a useful `__repr__` and equality.\" It's not a replacement for `class`, but it's handy for quick scripts or for converting a dict into a dotted-access object.\n\n---\n\n# Common Pitfalls\n\nSome pitfalls show up with instance attributes often enough to deserve direct attention.\n\n### Mutable Defaults Inside `__init__`\n\nIf a constructor parameter has a mutable default, every instance that uses the default ends up sharing one object:\n\n**What's wrong with this code?**\n\n\n```python\nclass Cart:\n def __init__(self, items=[]):\n self.items = items\n\ncart_a = Cart()\ncart_a.items.append(\"Mouse\")\n\ncart_b = Cart()\nprint(cart_b.items)\n```\n\n\nThe default `[]` is evaluated once when the `def` runs, and that one list is reused as the default for every call. `cart_a.items` and `cart_b.items` end up referring to the same list. The fix is the `None` sentinel pattern:\n\n**Fix:**\n\n\n```python\nclass Cart:\n def __init__(self, items=None):\n if items is None:\n items = []\n self.items = items\n```\n\n\nNow each call that omits `items` gets a fresh empty list. The trap applies to lists, dicts, sets, and any other mutable default; immutable defaults (`None`, `0`, `\"\"`, `()`) are fine.\n\n### Shadowing Class Attributes by Accident\n\nIf a class has an attribute (a shared default, a constant), and an assignment to the same name happens through `self`, the result is an instance attribute that shadows the class one. The class attribute still exists; the instance just stops seeing it:\n\n\n```python\nclass Product:\n tax_rate = 0.08 # class attribute (shared default)\n\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.tax_rate) # 0.08, from the class\n\nmouse.tax_rate = 0.05 # creates an instance attribute\nprint(mouse.tax_rate) # 0.05, from the instance\nprint(Product.tax_rate) # still 0.08, the class is untouched\n```\n\n\nThe third line reads from the class. The fourth line reads from the instance, which now has its own `tax_rate` shadowing the class's. The fifth line shows the class attribute is unchanged. This isn't necessarily a bug (overriding a default for one instance can be intentional), but it's a common source of confusion when an instance \"looks like\" it's set a shared value and the next instance doesn't see the change.\n\n### Typos Create New Attributes Instead of Erroring\n\nPython doesn't enforce a fixed set of attributes per class by default. A mistyped attribute name on the left side of an assignment doesn't raise an error; it creates a new attribute with the wrong name:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nmouse.prce = 24.99 # typo: meant to update price\n\nprint(mouse.price)\nprint(mouse.prce)\n```\n\n\nThe intent was to update `price`, but the typo `prce` created a new attribute. The original `price` is still `29.99`. This kind of bug is easy to introduce and frustrating to find, because the code runs without an error; it does the wrong thing without complaint.\n\nTools that help: type checkers like `mypy` warn about unknown attribute names when the class's attributes are declared (with annotations or `dataclasses`). Editors with Python language support catch many of these in real time. For classes where runtime enforcement matters, defining `__slots__` (covered briefly below) makes typos raise `AttributeError` immediately.\n\n---\n\n# `dataclasses` for Boilerplate-Free Instance Attributes\n\nA common pattern in Python classes is \"constructor that takes a bunch of values and stores them as instance attributes, plus a sensible `__repr__` and maybe equality\". The `dataclasses` module, added in Python 3.7, generates that boilerplate from a list of type-annotated attributes. They're worth introducing here because they directly solve the \"writing the same `__init__` over and over\" problem.\n\n\n```python\nfrom dataclasses import dataclass\n\n@dataclass\nclass Product:\n name: str\n price: float\n stock: int = 0\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nkeyboard = Product(\"Mechanical Keyboard\", 89.99)\n\nprint(mouse)\nprint(keyboard)\nprint(mouse.stock, keyboard.stock)\n```\n\n\nThe `@dataclass` decorator reads the annotated attributes (`name`, `price`, `stock`) and writes an `__init__` that takes them as parameters and stores them as instance attributes. The default value on `stock` becomes the default in the generated constructor. A useful `__repr__` and equality comparison are generated as well.\n\nDataclasses don't replace classes for everything. They fit when the class is mostly a structured bundle of data with a few methods. For substantial logic in the constructor (validation, derived values, complex setup), a hand-written `__init__` fits better.\n\n`@dataclass` runs at class-definition time, generating methods once when the class is loaded. There's no per-instance overhead at runtime; instances behave like instances of a hand-written class.\n\n---\n\n# A Quick Note on `__slots__`\n\nMost Python classes store attributes in `__dict__`. That allows flexibility (any attribute can be added at any time) but uses a few hundred bytes per instance for the dict's overhead. For classes that will create millions of instances and have a fixed attribute set, `__slots__` is an alternative storage mechanism:\n\n\n```python\nclass Product:\n __slots__ = (\"name\", \"price\", \"stock\")\n\n def __init__(self, name, price, stock):\n self.name = name\n self.price = price\n self.stock = stock\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nprint(mouse.name)\n\ntry:\n mouse.category = \"peripherals\" # not in __slots__\nexcept AttributeError as e:\n print(f\"rejected: {e}\")\n```\n\n\nWith `__slots__` declared, the class uses a fixed array of slots instead of a `__dict__`. Instances are smaller (no dict overhead) and attribute access is slightly faster. The trade-off is rigidity: only the names listed in `__slots__` can be set, so typos and dynamic additions raise `AttributeError`. That can be a feature (early failure on typos) or a constraint (no flexibility for extensions), depending on the use case.\n\nIt's good to know `__slots__` exists. For most code, plain classes with `__dict__` are the right choice. Use `__slots__` only when memory or attribute-typo enforcement is a measured concern.","pageType":"python"}

Instance Attributes

Get Premium