{"title":"__init__ Method","description":"","content":"A constructor is the method Python runs the instant a new object comes to life. For classes built around real data (a `Product` with a name and a price, a `Customer` with an email, an `Order` with an item list), the constructor is where that data gets attached to the instance so the rest of the program can use it. This lesson covers what `__init__` does, how to write one, how to set sensible defaults, how to validate inputs, and the small set of mistakes that bite almost everyone the first few times they write a class.\n\n---\n\n# What `__init__` Actually Is\n\n`__init__` is a regular method with a special name. Python looks for it on the class whenever you call the class like a function. The call `Product(\"Mouse\", 29.99)` is doing two things in sequence: it builds a brand-new, empty `Product` object, and then it hands that object to `__init__` so the method can fill it in. By the time the call returns, you have an instance whose attributes are already populated.\n\nHere is the smallest useful example:\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.name)\nprint(mouse.price)\n```\n\n\nThree things are worth pointing out here. First, `__init__` is never called as `__init__(...)` directly; you call the class, and Python calls `__init__` for you. Second, the first parameter is always `self`, which is the new instance Python just created and is now passing in for the method to set up. Third, every `self.something = value` line attaches an attribute to the instance, so after the constructor finishes, the object carries that data with it for the rest of its life.\n\nMost of the time, that is the whole job: take some arguments, validate them, store them on `self`. A class without an `__init__` is legal Python, but it's rare in practice, because almost every class you write exists to hold some state, and the constructor is the natural place to receive that state.\n\n---\n\n# When `__init__` Runs\n\n`__init__` runs exactly once per object, immediately after Python creates the empty instance and before the call expression that produced it returns. You don't trigger it; the moment you write `ClassName(...)`, the constructor fires. There is no separate \"create\" then \"initialize\" step you have to remember; Python wires the two together.\n\nA quick way to see this is to print from inside `__init__`:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n print(f\"building a Product for {name}\")\n self.name = name\n self.price = price\n\nprint(\"before the call\")\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(\"after the call\")\n```\n\n\nThe `print` inside `__init__` lands between the two outer prints, which is exactly where the constructor runs. The call expression `Product(\"Wireless Mouse\", 29.99)` doesn't return until the constructor finishes setting up the instance.\n\nTwo consequences fall out of this. The constructor runs once per instance, not once per class, so creating ten `Product` objects calls `__init__` ten times, each with its own `self`. And anything that happens during `__init__` (printing, opening files, reading config) happens every time you build an instance, which is one reason to keep the constructor focused on assignment rather than expensive setup.\n\n\n```mermaid\nflowchart LR\n Call[\"Product('Mouse', 29.99)\"]:::cyan\n New[\"__new__
creates empty instance\"]:::orange\n Init[\"__init__
fills attributes\"]:::green\n Return[\"return instance to caller\"]:::teal\n\n Call --> New --> Init --> Return\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 teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the full path of a `Product(\"Mouse\", 29.99)` call. The two methods Python uses behind the scenes are `__new__` (which builds the empty object) and `__init__` (which fills it in). For almost every class you write, you only need to define `__init__` and let Python's default `__new__` handle the creation step.\n\n---\n\n# Defining `__init__` With Parameters\n\nThe parameter list of `__init__` is the shape of the constructor call. Whatever you list there, after `self`, is what callers have to provide when they build an instance. Add a parameter and the call gains an argument; remove one and it loses one.\n\n\n```python\nclass Customer:\n def __init__(self, name, email, address):\n self.name = name\n self.email = email\n self.address = address\n\nalice = Customer(\"Alice\", \"alice@example.com\", \"10 Park Lane\")\nprint(alice.name)\nprint(alice.email)\nprint(alice.address)\n```\n\n\nThree parameters in the constructor, three arguments at the call site, three attributes on the instance. The names don't have to match (you could write `self.name = name_arg` if the parameter were called `name_arg`), but matching them is the common convention and reads cleanly.\n\nConstructors accept positional and keyword arguments just like any other function:\n\n\n```python\nclass Order:\n def __init__(self, order_id, customer_name, status):\n self.order_id = order_id\n self.customer_name = customer_name\n self.status = status\n\n# positional\norder_a = Order(101, \"Alice\", \"placed\")\n\n# keyword (clearer when there are several arguments)\norder_b = Order(order_id=102, customer_name=\"Bob\", status=\"shipped\")\n\nprint(order_a.order_id, order_a.status)\nprint(order_b.order_id, order_b.status)\n```\n\n\nKeyword arguments are useful once a constructor takes more than two or three parameters, because the call site stops looking like a row of mystery values. If you read `Order(102, \"Bob\", \"shipped\")` cold, you have to remember the parameter order. `Order(order_id=102, customer_name=\"Bob\", status=\"shipped\")` tells you what each value is on sight.\n\nYou can also accept `*args` and `**kwargs` in `__init__` if you genuinely need a variable number of arguments, but this is rare for everyday classes and usually a sign that the design wants to be reconsidered. Most constructors take a small, fixed set of named parameters.\n\n---\n\n# Setting Instance Attributes Inside `__init__`\n\nThe body of `__init__` is the natural place to attach data to the new instance. Every assignment to `self.something` inside the constructor creates an attribute on that specific instance. The same attribute name on two different objects refers to two different values, because each call to `__init__` has its own `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\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nkeyboard = Product(\"Mechanical Keyboard\", 89.99, 12)\n\nprint(f\"{mouse.name}: ${mouse.price}, {mouse.stock} in stock\")\nprint(f\"{keyboard.name}: ${keyboard.price}, {keyboard.stock} in stock\")\n```\n\n\nEach `Product` carries its own `name`, `price`, and `stock`. Changing one instance's `stock` does not touch the other, because `self` in each call pointed at a different object.\n\nYou can also compute attributes inside `__init__`, not just store the parameters as-is. A common pattern is to derive one attribute from the others:\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\"Subtotal: ${cart.subtotal:.2f}\")\nprint(f\"Total: ${cart.total:.2f}\")\n```\n\n\n`subtotal` and `total` are not constructor parameters; they're computed from `items` and `tax_rate` and stored alongside them. The caller doesn't have to compute them; the constructor does it once and the values are then available as attributes for the life of the instance.\n\nOne catch worth knowing now: these computed attributes are a snapshot taken at construction time. If the caller later mutates `cart.items` (appends to it, for example), `cart.subtotal` does not update on its own; it's just a number that was assigned during `__init__`. Keeping derived values in sync with their source is its own design question, and the `@property` decorator is one common answer. For this lesson, the takeaway is just that `__init__` sets attributes once, not continuously.\n\n---\n\n# Default Parameter Values\n\nIf a constructor parameter has a sensible default, you can give it one in the parameter list, and callers who don't care about that parameter can leave it out:\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock=0, category=\"general\"):\n self.name = name\n self.price = price\n self.stock = stock\n self.category = category\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nkeyboard = Product(\"Mechanical Keyboard\", 89.99, stock=12, category=\"peripherals\")\n\nprint(f\"{mouse.name}: stock={mouse.stock}, category={mouse.category}\")\nprint(f\"{keyboard.name}: stock={keyboard.stock}, category={keyboard.category}\")\n```\n\n\nThe `mouse` call only provides the two required parameters, so `stock` defaults to `0` and `category` to `\"general\"`. The `keyboard` call overrides both defaults. This is the same default-argument behavior any Python function has; `__init__` is not special in that regard.\n\nDefaults make a class friendlier to call when only a few attributes vary from one instance to the next. They also document the \"normal\" or \"expected\" value of an attribute at a glance: reading `stock=0` in the signature tells you that a freshly created product starts with no stock.\n\n### The Mutable Default Argument Trap\n\nThere is one trap with default arguments that hits people hard the first time, and it bites just as much inside `__init__` as in any other function. Don't use a mutable object (a list, dict, or set) as a default value.\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()\ncart_b.items.append(\"Keyboard\")\n\nprint(cart_a.items)\nprint(cart_b.items)\n```\n\n\nBoth carts share the same list. The default value `[]` is evaluated exactly once, when the `def` statement runs (which is when the class is being defined), and that single list object becomes the default for every future call that doesn't pass `items`. So `cart_a.items` and `cart_b.items` are the same list. Mutating it through one cart shows up through the other.\n\nThe fix is to use `None` as the sentinel default and build a fresh container inside the body:\n\n\n```python\nclass Cart:\n def __init__(self, items=None):\n if items is None:\n items = []\n self.items = items\n\ncart_a = Cart()\ncart_a.items.append(\"Mouse\")\n\ncart_b = Cart()\ncart_b.items.append(\"Keyboard\")\n\nprint(cart_a.items)\nprint(cart_b.items)\n```\n\n\nNow every caller that omits `items` gets a brand-new empty list, because the `[]` runs each time the body executes. `None` is fine as a default because `None` is immutable; the trap only applies to mutable defaults like lists, dicts, and sets.\n\n\n> **INFO**\n>\n> **Cost:** This isn't really a performance issue, it's a correctness one. The shared-state bug usually shows up far away from the constructor (a second test failing for \"no reason\", a customer's cart having someone else's items). The cost of getting it wrong is debugging time, not CPU time.\n\n\n---\n\n# Validating Input Inside `__init__`\n\nThe constructor is a good place to reject obviously bad data. If a `Product` price can't be negative and a `Review` rating must be between 1 and 5, the constructor can check those rules and raise an exception when they're violated. That stops broken objects from coming into existence in the first place, which is much easier to reason about than catching the error later when some downstream code trips over it.\n\n\n```python\nclass Product:\n def __init__(self, name, price, stock=0):\n if not name:\n raise ValueError(\"name must be a non-empty string\")\n if price < 0:\n raise ValueError(f\"price must be non-negative, got {price}\")\n if stock < 0:\n raise ValueError(f\"stock must be non-negative, got {stock}\")\n self.name = name\n self.price = price\n self.stock = stock\n\nmouse = Product(\"Wireless Mouse\", 29.99, 50)\nprint(f\"{mouse.name}: ${mouse.price}\")\n\ntry:\n Product(\"Broken Mouse\", -5.00)\nexcept ValueError as e:\n print(f\"rejected: {e}\")\n```\n\n\nThe first construction succeeds because all three values pass the checks. The second call fails the `price < 0` check, and the constructor raises `ValueError` before any attributes are set. Callers can then catch that error and handle it (log it, return a friendly message, retry with corrected input).\n\nA few small rules for validation inside `__init__`:\n\n- **Validate before assigning.** Check the values first, then assign to `self`. If you assign and then raise, you leave the half-built object in an unclear state, even though Python is about to discard the reference; the order also makes the code easier to read.\n- **Raise the right exception type.** `ValueError` for bad values, `TypeError` for wrong types, `KeyError` for missing keys. Don't use bare `Exception`.\n- **Include the bad value in the message.** `\"price must be non-negative, got -5.0\"` is much more debuggable than `\"invalid price\"`.\n\nAnother example with rating bounds:\n\n\n```python\nclass Review:\n def __init__(self, product_id, rating, comment=\"\"):\n if not isinstance(rating, int):\n raise TypeError(f\"rating must be an int, got {type(rating).__name__}\")\n if not 1 <= rating <= 5:\n raise ValueError(f\"rating must be between 1 and 5, got {rating}\")\n self.product_id = product_id\n self.rating = rating\n self.comment = comment\n\ngood_review = Review(101, 5, \"Smooth and quiet\")\nprint(f\"product {good_review.product_id}: {good_review.rating} stars\")\n\ntry:\n Review(101, 7, \"Too good\")\nexcept ValueError as e:\n print(f\"rejected: {e}\")\n\ntry:\n Review(101, \"five\", \"Wrong type\")\nexcept TypeError as e:\n print(f\"rejected: {e}\")\n```\n\n\nTwo different mistakes, two different exception types. A caller can tell them apart in a `try/except` and react accordingly. The constructor draws the line: by the time an instance exists, you know its `rating` is an integer in the valid range.\n\n---\n\n# `__new__` vs `__init__` (Brief)\n\nPython actually uses two methods to build an object, not one. `__new__` creates the empty instance, and `__init__` fills it in. The class call (`Product(...)`) calls `__new__` first, which returns a new (typically empty) object of the class, and then Python passes that object to `__init__` as `self`.\n\nFor almost every class you write, you don't define `__new__`. Python's default version, inherited from `object`, just allocates a new instance and hands it back, which is the right behavior 99% of the time. You write `__init__` and ignore `__new__` entirely.\n\nA minimal illustration:\n\n\n```python\nclass Product:\n def __new__(cls, *args, **kwargs):\n print(\"__new__ runs: building the empty instance\")\n return super().__new__(cls)\n\n def __init__(self, name, price):\n print(f\"__init__ runs: filling in {name}\")\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(f\"final: {mouse.name} at ${mouse.price}\")\n```\n\n\nThe order makes the split visible: `__new__` returns the empty object, then `__init__` is handed that object as `self` and fills in the attributes. The two methods together are what the single call `Product(\"Wireless Mouse\", 29.99)` actually triggers.\n\n`__new__` becomes interesting in a narrow set of cases: subclassing immutable types like `int` or `tuple` (where the value has to be set during creation, not after), implementing the singleton pattern, or building objects through a factory that returns instances of a different class. None of those are everyday work, and the moment you reach for `__new__`, you've left beginner Python.\n\nFor this section, here is the one-line summary to carry forward: `__init__` is the constructor you write, `__new__` is the creator Python runs first, and you can safely ignore `__new__` until you have a concrete reason to override it.\n\n---\n\n# Common Mistakes\n\nA handful of mistakes show up over and over in newly written `__init__` methods. Recognizing them early saves a lot of time.\n\n### Forgetting `self`\n\nThe first parameter of every method, including `__init__`, has to be `self`. Drop it, and Python's error message is not the one most people expect:\n\n\n```python\nclass Product:\n def __init__(name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\n```\n\n\nThe error is confusing because the call passes two arguments, but Python is counting three: the implicit instance Python created plus the two values from the call. The fix is to put `self` back as the first parameter:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n```\n\n\n`self` is not a keyword; it's just a parameter name, and you could technically call it `this` or `instance` or any other valid identifier. Don't. Every Python codebase calls it `self`, and breaking that convention only makes your code harder to read.\n\n### Assigning to a Local Instead of `self`\n\nInside the constructor body, an assignment without `self.` creates a local variable that vanishes when the method returns. It does not attach anything to the instance.\n\n**What's wrong with this code?**\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n name = name\n price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.name)\n```\n\n\n`name = name` just reassigns the local parameter to itself. The instance never gets a `name` attribute, so reading `mouse.name` later fails. The fix is to prefix the left-hand side with `self.`:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n```\n\n\nThe right-hand side is the parameter; the left-hand side, with `self.`, is the attribute Python creates on the new instance. The two pieces have the same word in them, but they're different things.\n\n### Mutable Default Arguments\n\nWe already covered this one in the defaults section, but it deserves a second mention here because it is the single most common bug in newly written constructors. If a parameter's default is a list, dict, or set, every instance that uses the default shares the same object. Always use `None` as the sentinel and build the container inside the body.\n\n\n```python\n# wrong\nclass Cart:\n def __init__(self, items=[]):\n self.items = items\n\n# right\nclass Cart:\n def __init__(self, items=None):\n if items is None:\n items = []\n self.items = items\n```\n\n\nThe same trap applies to `{}` (use `None` and assign `{}` inside) and to `set()` (use `None` and assign `set()` inside).\n\n### Doing Too Much in `__init__`\n\nThe constructor's job is to put the instance into a usable state, not to run the program. Heavy operations like reading large files, making network calls, or building expensive data structures should not happen in `__init__`. They make every object slow to create, hard to test (you can't construct one without the slow operation also running), and surprising to use.\n\n\n```python\n# not great: every Product construction reads a 100 MB pricing file\nclass Product:\n def __init__(self, name):\n self.name = name\n with open(\"pricing.csv\") as f:\n self.price = self._lookup_price(f, name)\n```\n\n\nA cleaner separation is to keep `__init__` focused on assigning attributes from its arguments and to put the expensive work behind a method or a class method the caller invokes when needed:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\n @classmethod\n def from_pricing_file(cls, name, path):\n with open(path) as f:\n price = cls._lookup_price(f, name)\n return cls(name, price)\n```\n\n\nThe point is just that `__init__` is best kept small and focused. Save the heavy lifting for explicit methods or factories.\n\nA reasonable rule of thumb: if `__init__` has more than a dozen lines and isn't mostly assignments to `self`, it is probably doing too much.","pageType":"python"}

__init__ Method

Get Premium

init Method