Python Constructors with `__init__()`

The Python constructor method, written with the special name init and pronounced "dunder init," is the function that runs every time a new object is created from a class. Its single responsibility is to take a freshly allocated object and set it up with the attributes and initial values that define what that object is. When you write a line like account = BankAccount("Maya Johnson", 500), Python creates an empty BankAccount object in memory and then calls the init method on that object, passing "Maya Johnson" and 500 as arguments alongside the object itself. By the time init returns, the object is fully initialized with a predictable set of attributes that every other method in the class can rely on. The constructor is the gatekeeper for object state, and designing it well is one of the highest-leverage decisions you make when writing a Python class.

Every Python class you have written in this section has included an init method, and by now the syntax is familiar. But the design decisions inside init, which parameters to require, which to make optional, how to validate input, and how much logic to place in the constructor versus in separate methods, have a large impact on how usable and maintainable the class becomes. A constructor that demands five required positional arguments with no defaults is hard to use correctly because callers must remember the exact order. A constructor that accepts any input without validation allows objects to exist in invalid states, pushing error detection downstream to whatever method first encounters the bad data. Getting the constructor right means finding the balance between flexibility and safety that fits the class's purpose.

If you have read the article on the self parameter, you understand how Python passes the object as the first argument to every instance method. The init method is an instance method like any other, which means it receives self as its first parameter and can assign attributes to that object. The only thing that makes init special is that Python calls it automatically during object creation, and you never call it directly on an existing object after creation. This article explores the patterns and practices that turn a basic init into a well-designed constructor.

What happens during object creation

Understanding the sequence of events during object creation clarifies what init can and cannot do. When Python encounters a class name followed by parentheses, as in BankAccount("Maya Johnson", 500), it performs two distinct steps. First, it calls the class's new method, which is responsible for actually creating the object in memory and returning it. The new method is rarely overridden in everyday Python code, so you can treat it as a black box that produces an empty object of the correct type. Second, Python calls init on that newly created object, passing the arguments from the constructor call. The init method receives an already-existing object as self and its job is purely to set attributes on that object. It does not create the object, and it should not return anything other than None.

This two-step process means that init can assume the object already exists when its code runs. You can assign attributes, call methods on other objects, open files, establish network connections, and perform any other setup that the object needs. But you should be aware that if init raises an exception, the partially initialized object may still exist in memory until Python's garbage collector reclaims it. For most beginner and intermediate use cases, this detail does not matter, but it reinforces the importance of performing input validation early in init so that invalid objects are never fully constructed.

Here is a straightforward constructor that demonstrates the pattern of setting required attributes and initializing internal data structures:

python

class Student:
    def __init__(self, name, student_id):
        self.name = name
        self.student_id = student_id
        self.enrollments = []
        self.active = True

The name and student ID come from the caller and are stored directly on the object. The enrollments list is initialized to empty; no caller provides initial enrollment data, but every Student object needs the list to exist so that methods can append to it later without checking whether it has been created. The active flag is set to True as a sensible default for a newly created student. Every attribute that any method in the class might access is set inside init, which means no method ever needs to guard against an attribute not existing.

Required parameters, optional parameters, and defaults

The parameter list of init defines the contract between the class and the code that creates its objects. Required parameters without default values force the caller to provide those values, ensuring that every object has the essential data it needs to function. Optional parameters with default values let callers omit information that has a sensible fallback, reducing the friction of creating objects while still allowing customization when needed.

A common pattern is to make the most essential attributes required and to provide defaults for attributes that can start with a standard value. A Customer class might require a name and an email address because those are essential to the concept of a customer. A loyalty points counter might default to zero because a new customer has no points yet. A preferred contact method might default to email because that is the most common choice. The parameter list communicates which information is mandatory and which is optional without requiring the caller to read documentation:

python

class Customer:
    def __init__(self, name, email, loyalty_points=0, contact_method="email"):
        self.name = name
        self.email = email
        self.loyalty_points = loyalty_points
        self.contact_method = contact_method

The caller can create a basic customer with just a name and email, or can specify points and contact method when those values are known. The constructor handles both cases without multiple overloaded versions or conditional logic, which is one of the benefits of Python's support for default parameter values.

A subtle but important rule about default parameter values applies to constructors just as it applies to regular functions. Default values are evaluated once, at the time the function is defined, not each time the function is called. This means you should never use a mutable object like a list or dictionary as a default parameter value, because every call that uses the default will share the same mutable object. If one object modifies the shared list, the change is visible to every other object that used the default. The correct pattern is to use None as the default and create the mutable object inside the method body, as shown with the enrollments list in the earlier Student example.

Input validation in the constructor

The constructor is the ideal place to validate input because it runs before the object is used for anything else. If a caller passes a negative value for a quantity that must be positive, or an empty string for a name that must be non-empty, raising an exception inside init prevents the invalid object from ever existing in a usable state. This pattern, called failing fast, makes bugs easier to find because the error occurs at the moment of creation rather than later when the invalid data causes a more confusing failure in an unrelated method.

Validation inside init can be as simple as an if statement that checks a condition and raises a ValueError with a descriptive message. For a BankAccount class that requires a positive initial balance, the validation might look like this:

python

def __init__(self, account_holder, initial_balance):
    if initial_balance < 0:
        raise ValueError("Initial balance cannot be negative")
    self.account_holder = account_holder
    self.balance = initial_balance

The validation runs before any attributes are set, so the object never exists with a negative balance. The exception message tells the caller exactly what went wrong, which is more helpful than a generic error deep in the withdrawal logic later. For more complex validation, the logic can be extracted into a separate method, but the principle remains the same: check inputs early, raise clear errors, and only proceed to attribute assignment once all checks pass.

Keeping constructors focused

A constructor should set up the object's initial state and do little else. It should not perform expensive computations, make network requests, read large files, or start background threads unless those actions are essential for the object to function and the caller explicitly expects them from construction. Expensive setup that can be deferred should be moved into a separate method that the caller invokes when ready. This separation gives callers control over when heavy work happens and makes the class easier to use in contexts where construction needs to be fast, such as creating many objects in a loop.

If an object requires complex setup that involves multiple steps, consider providing a class method as an alternative constructor. The class method can orchestrate the setup steps and then call the primary constructor with the prepared data. This pattern keeps init simple while still providing a convenient creation path for callers who need the full setup. The article on class methods in Python covers this factory pattern in detail.

A well-designed init is one of the first things another developer reads when they encounter your class, and it sets expectations for how the rest of the class works. A constructor that is short, clear about what it requires, and careful about validation communicates that the class is well thought out and safe to use. A constructor that is long, cryptic, or permissive about invalid input communicates the opposite. The time you invest in getting the constructor right pays off every time you or someone else creates an object from your class.