Classes & Objects

Almost everything you touch in Python is an object: a string, a list, a file, even a function. A class is the blueprint that says what an object holds and what it can do. Once you can write your own classes, you stop passing five loose variables around and start bundling them with the code that works on them, so a User, an Order or a Timer becomes one tidy thing you can create, pass around and reason about.

This matters because nearly every real Python codebase is built from classes, and the libraries you use daily (datetime, pathlib, requests, Django, pandas) expose them everywhere. Reading that code, and writing code others can read, depends on a handful of ideas that this chapter takes one at a time: how __init__ and self work, where data lives, how inheritance and super() share behaviour, and how special methods and @property make your objects feel like built-in ones.

By the end you will be able to design and write small classes with clean attributes and methods, give them readable printing and comparison, choose between inheritance and composition, and cut boilerplate with dataclasses. You will also recognise the classic traps, such as a shared mutable class attribute or a forgotten super().__init__(), before they cost you an afternoon of debugging.

Python programs often need many objects of the same kind: a hundred dogs, a thousand orders, a handful of database connections. Writing each one by hand would be tedious. A class is the blueprint that describes what such an object looks like and what it can do. You create it once with the class statement.

A blueprint is not a house. To get something you can use, you call the class like a function. Each call builds one new object, called an instance. In d = Dog(), Dog is the class and d is an instance of it.

class Dog:
    pass

d = Dog()
print(type(d).__name__)
print(isinstance(d, Dog))

The smallest possible class, and one instance of it

The body of this class is just pass, so it does nothing yet. It is still a real class, and Dog() still gives you a real object. Later sections fill the blueprint with data and behaviour.

You can call the class as many times as you like. Every call gives a separate instance, even though all of them follow the same blueprint.

a = Dog()
b = Dog()
print(a is b)
print(a == b)
print(type(a) is type(b))

Two instances from the same class are still two different objects

a is b asks whether both names point at the very same object, and they do not. a == b is also False because a plain class has no idea how to compare its instances, so Python falls back to identity. Both objects do share one class, which is why the last line is True.

In Python, nearly everything is an object, and that includes classes. When Python runs a class statement, it creates an object and binds it to the class name. You can pass Dog to a function, store it in a list or inspect it, just like a number or a string.

Every object has a type, and the built-in type() function tells you what it is. The type of an instance is its class. The type of a class is type, which is the thing that builds classes.

print(type(d))
print(type(Dog))
print(type(d) is Dog)
print(type(Dog) is type)
print(Dog.__name__)

type() of an instance, and type() of the class itself

Read the first two lines as a chain. d is an instance of Dog, and Dog is an instance of type. That is why a class can have attributes of its own, such as Dog.__name__, which holds the name you wrote after the class keyword.

Each instance keeps its own data. Python stores that data in a dictionary called __dict__, which maps attribute names to values. Setting rex.name = 'Rex' simply adds the key 'name' to the __dict__ of rex and to no other object.

rex = Dog()
rex.name = 'Rex'
rex.age = 3

fido = Dog()
fido.name = 'Fido'

print(rex.__dict__)
print(fido.__dict__)
rex.age = 4
print(rex.__dict__['age'])

Two instances of one class, each with its own attributes

rex and fido come from the same class, yet their dictionaries differ. fido never got an age, and changing rex.age did not affect anything else. Looking at __dict__ is a handy way to see exactly what an object currently holds.

The last tool for this section is isinstance(obj, cls). It answers whether obj was built from cls, or from a class that inherits from it. It is more flexible than type(obj) is cls, which accepts only the exact class.

print(isinstance(rex, Dog))
print(isinstance(Dog, type))
print(isinstance(rex, str))
print(isinstance(rex, object))

isinstance checks the relationship between an object and a class

Writing Dog('Rex') looks like one step, but Python does two jobs behind the scenes. First it calls __new__, which builds a brand-new, empty object in memory. Then it calls __init__ on that object, which fills it in with the starting data you care about. You almost never write __new__ yourself; you write __init__.

Notice that __init__ is not what makes the object. It receives an object that already exists and decorates it. That is why __init__ has no job of handing anything back, and why Python insists that it returns None. The finished object comes from the Dog(...) call itself, not from __init__.

class Dog:
    def __new__(cls, name):
        print('__new__ creating the object')
        return super().__new__(cls)

    def __init__(self, name):
        print('__init__ setting up', name)
        self.name = name

d = Dog('Rex')
print(d.name)

Both hooks announce themselves, so you can see the order.

Inside a class, every ordinary method receives the object it was called on as its first parameter. By convention that parameter is named self. There is nothing magical about it: when you write d.bark(), Python looks up bark on the class and passes d in automatically. So d.bark() is just friendly shorthand for Dog.bark(d).

class Dog:
    def __init__(self, name):
        self.name = name

    def bark(self):
        return self.name + ' says woof'

d = Dog('Rex')
print(d.bark())
print(Dog.bark(d))
print(d.bark() == Dog.bark(d))

The two calls are the same call written two ways.

This also explains a classic error. If you define def bark(): with no parameters, calling d.bark() quietly passes d as an argument the method has no room for, and Python complains about the argument count.

Inside __init__, the parameter name is an ordinary local variable. It lives only while __init__ runs and vanishes when it ends. To keep the value on the object, attach it with self.name = name. The left side is an attribute on the object; the right side is the local parameter being copied in.

class Lost:
    def __init__(self, name):
        name = name          # only a local variable

class Kept:
    def __init__(self, name):
        self.name = name     # stored on the object

print(hasattr(Lost('Rex'), 'name'))
print(Kept('Rex').name)

The bare assignment disappears the moment __init__ finishes.

An object bundles two kinds of things: the data it remembers and the things it can do. In Python the data lives in attributes and the actions live in methods. Both are looked up with a dot, which is why they are easy to mix up at first.

An attribute is a named value stored on an object, such as self.age. A method is a function defined inside the class body whose first parameter is self, so it can read and change the attributes of the object it was called on.

In the example below, name and age are attributes set in __init__. bark reads an attribute and builds a message, while birthday changes an attribute. Notice that self is the way a method reaches the data of its own object.

You never write d.bark(d), yet bark has a self parameter. The reason is that Python treats a function differently depending on how you reach it. When you look the function up through an instance, Python wraps it in a bound method: a small object that remembers the instance and the original function, and passes that instance as the first argument when it is called.

Looked up on the class instead, there is no instance to remember, so Dog.bark is just the plain function. It is not bound to anything, which means you have to supply self yourself.

The following example shows each of those facts. It prints only things that are the same on every run, because the memory addresses inside a printed method change from run to run and from machine to machine.

print(type(Dog.bark).__name__)
print(type(d.bark).__name__)
print(d.bark.__self__ is d)
print(d.bark.__func__ is Dog.bark)
print(Dog.bark(d))
print(d.bark() == Dog.bark(d))

Both spellings run the very same function

The bound method keeps the instance in __self__ and the original function in __func__. Calling d.bark() is therefore just a shorter way to write Dog.bark(d).

Writing d.bark without parentheses does not run anything. It gives you the bound method object itself, which you can store in a variable, pass to another function, and call later. Only the parentheses in d.bark() actually execute the body.

ref = d.bark
print(callable(ref))
print(repr(ref).startswith("<bound method Dog.bark of"))
print(ref())

ref remembers d, so calling it later still works

The printed form of a bound method contains the words bound method, the qualified name Dog.bark, and the instance it is attached to. Seeing text like that in your output is a strong hint that you forgot the parentheses.

Python also lets you attach new attributes to an instance after it has been created, because an instance keeps its attributes in its own dictionary. That is handy, but it means a typo in an attribute name quietly creates a new attribute instead of raising an error.

d.color = "brown"
print(d.color)
print(sorted(vars(d)))
other = Dog("Fido", 1)
print(hasattr(other, "color"))

The new attribute belongs to d only

A Python object can hold data in two places. A class attribute is a name you assign directly in the class body, so it belongs to the class itself and every instance can see the same one. An instance attribute is a name you set on self, usually inside __init__, so each object gets its own private copy.

Think of a class attribute as a sign on the wall of a kennel that every dog can read, and an instance attribute as the name tag on each dog's collar. In the example below, species is shared, while name differs per dog.

class Dog:
    species = "Canis familiaris"   # class attribute: one copy, shared

    def __init__(self, name):
        self.name = name            # instance attribute: one per object

rex = Dog("Rex")
fido = Dog("Fido")

print(rex.name, fido.name)
print(rex.species, fido.species)
print(rex.species is fido.species)
print(Dog.species)

species lives on the class; name lives on each instance

Notice that rex.species and fido.species are the very same object, which is why is reports True. Neither dog stores it. Both simply find it on the class.

When you write rex.species, Python does not look in just one place. It searches in a fixed order and stops at the first match. First it checks the instance's own __dict__, which holds the instance attributes. If the name is missing there, it checks the class. If it is still missing, it walks up through the parent classes. Only after all of that fails does it raise AttributeError.

You can see this for yourself by printing the dictionaries. The instance dictionary contains only what was set on self, so species is absent from it even though rex.species works.

class Animal:
    legs = 4

class Dog(Animal):
    species = "Canis familiaris"

    def __init__(self, name):
        self.name = name

rex = Dog("Rex")
print(rex.__dict__)
print("species" in rex.__dict__)
print(rex.species)   # found on Dog
print(rex.legs)      # found on Animal, the parent

legs is found by walking up from Dog to Animal

Reading and writing are not symmetric. Reading d.count follows the lookup chain, but writing d.count = 5 always stores the value in the instance's __dict__. It never reaches up and changes the class. The new instance attribute then shadows the class one, because the instance is checked first. Other instances, and the class itself, are untouched.

class Dog:
    count = 0

d = Dog()
e = Dog()

d.count = 5          # creates an instance attribute on d

print(d.count)       # 5, found in d.__dict__ first
print(e.count)       # 0, still reading the class
print(Dog.count)     # 0, the class is unchanged
print(d.__dict__)

del d.count          # remove the shadow
print(d.count)       # 0 again, back to the class value

Deleting the instance attribute reveals the class attribute again

class Dog:
    count = 0

    def __init__(self):
        Dog.count += 1   # writes to the class, shared by everyone

Dog(); Dog(); Dog()
print(Dog.count)

Use the class name to update shared state

class Safe:
    def __init__(self):
        self.tags = []     # a fresh list for each instance

a, b = Safe(), Safe()
a.tags.append("python")
print(a.tags, b.tags)

The corrected version

Sometimes a new class is just a more specific version of one you already have. A puppy is a dog, so it should do everything a dog does without you copying the code. Inheritance handles this: you name the existing class in parentheses, and the new class gets all of its attributes and methods.

The class you inherit from is the parent (or base class). The new class is the child (or subclass). In class Puppy(Dog), Dog is the parent and Puppy is the child. Python builds the child's __init__, sleep and speak from the parent unless the child says otherwise.

To change a behaviour, override it by defining a method with the same name in the child. When you call the method on a Puppy, Python finds the child's version first and uses it. Methods you don't redefine are still inherited.

class Dog:
    def __init__(self, name):
        self.name = name

    def speak(self):
        return f'{self.name} says woof'

    def sleep(self):
        return f'{self.name} is asleep'


class Puppy(Dog):
    def speak(self):
        return f'{self.name} says yip'


p = Puppy('Bit')
print(p.speak())
print(p.sleep())

Puppy defines no __init__ and no sleep, yet both work.

speak came from Puppy because it was overridden. sleep and __init__ came from Dog, which is why Puppy('Bit') worked and set name.

Overriding __init__ needs more care than overriding other methods. If a child defines its own __init__, Python uses only that one and never calls the parent's automatically. Anything the parent's __init__ would have set up is then missing.

The fix is super().__init__(...). The call super() gives you access to the parent's version of a method, so you can run the parent's setup first and then add what is specific to the child. The same trick works for any overridden method when you want to extend the parent's behaviour instead of replacing it.

class Puppy(Dog):
    def __init__(self, name, age_months):
        super().__init__(name)
        self.age_months = age_months

    def speak(self):
        return super().speak() + ' (squeaky)'


p = Puppy('Bit', 3)
print(p.name, p.age_months)
print(p.speak())

A fuller Puppy: parent setup, one new attribute, and an extended method.

super().__init__(name) let Dog store name, and Puppy stored only age_months itself. In speak, super().speak() reused the dog's sentence and the puppy added to it.

Now see what happens when the call is skipped. The child's __init__ runs, but the parent's never does, so name is never created.

Because a puppy is a dog, code that expects a Dog should accept a Puppy too. isinstance(obj, Class) asks whether an object is an instance of a class or of any class derived from it. issubclass(Child, Parent) asks the same question about two classes, with no object involved.

The relationship only goes one way. A puppy counts as a dog, but a plain dog does not count as a puppy. The last two lines show that comparing type(p) with a class demands an exact match, which is much stricter than isinstance.

So far each class had one parent. Python also lets a class list several parents in its parentheses, as in class C(A, B). The new class gets the methods and attributes of all of them, which is handy when you want to mix small, separate abilities into one class.

The obvious question is what happens when two parents define a method with the same name. Python answers with a fixed lookup sequence called the method resolution order, or MRO. When you call obj.method(), Python walks the MRO from left to right and uses the first class that defines the name.

class Swimmer:
    def move(self):
        return 'swim'

class Walker:
    def move(self):
        return 'walk'

    def rest(self):
        return 'sit down'

class Duck(Swimmer, Walker):
    pass

class Robot(Walker, Swimmer):
    pass

d = Duck()
print(d.move())
print(d.rest())
print(Robot().move())

Both parents define move(); the order in the parentheses decides the winner.

Duck finds move in Swimmer first, so it swims. rest exists only in Walker, so the search continues past Swimmer and finds it there. Robot lists the same parents in the opposite order, so it walks. The left-to-right order you write is part of the class design.

You do not have to guess the order. Every class stores it in __mro__, a tuple, and ClassName.mro() returns the same thing as a list. Python builds it with an algorithm called C3 linearization, which keeps each class before its parents and keeps the order of the bases you wrote. Every class ends with object.

The trickiest shape in multiple inheritance is the diamond. Two classes inherit from the same base, and a fourth class inherits from both of those. Drawn out, the four classes form a diamond with the shared base at the top.

The problem is that Bottom reaches Base along two paths. If each middle class calls Base.__init__(self) by name, the base setup runs twice. That can mean duplicate work, double-registered resources or a counter that goes up twice. Here is that naive version.

class Base:
    def __init__(self):
        print('Base init')

class Left2(Base):
    def __init__(self):
        print('Left2 init')
        Base.__init__(self)

class Right2(Base):
    def __init__(self):
        print('Right2 init')
        Base.__init__(self)

class Bottom2(Left2, Right2):
    def __init__(self):
        print('Bottom2 init')
        Left2.__init__(self)
        Right2.__init__(self)

Bottom2()

Calling parents by name: Base runs twice.

The fix is super(). It does not mean "my one parent". It means "the next class after me in the MRO of the object I am working on". Since the MRO lists each class exactly once, a chain of super() calls visits every class once and Base runs a single time.

Look at what happened inside Left. Its super().__init__() ran Right.__init__, not Base.__init__, because Right comes next in the MRO of a Bottom object. Right then passed control on to Base. The call chain follows the MRO, so every class runs once and Base runs last.

Methods whose names start and end with double underscores are called dunder methods. You almost never call them directly. Python calls them for you when you use built-in syntax such as print(), == or len(). By defining them, you teach your own class to behave like a built-in type.

The first pair controls how an object turns into text. __repr__ is meant for developers: it should be unambiguous and, ideally, look like the code that would rebuild the object. __str__ is meant for readers: it should be friendly and short. print() and str() use __str__, while the REPL, debuggers and repr() use __repr__.

Without either method, Python prints something like <__main__.Point object at 0x...>, which tells you nothing about the data inside. Here a class defines only __repr__:

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __repr__(self):
        return f"Point({self.x}, {self.y})"

p = Point(2, 3)
print(p)
print([p])
print(str(p), repr(p))

Only __repr__ is defined, and print still uses it

Notice that print(p) worked even though we never wrote __str__. When __str__ is missing, Python falls back to __repr__. The reverse is not true: a missing __repr__ does not borrow from __str__. Containers such as lists always use repr() for the items inside them, which is why the list above shows Point(2, 3).

When you define both, each does its own job:

The == operator calls __eq__. If your class does not define it, Python inherits the default from object, which compares identity: two names are equal only if they point to the very same object. So two objects holding identical data are still unequal.

class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

a = Point(1, 2)
b = Point(1, 2)
print(a == b, a is b)
print(a == a)

No __eq__ yet, so == falls back to identity

To say that equal-looking points should be equal, define __eq__. It receives the other object. If that object is not something you know how to compare, return NotImplemented instead of False, so Python can try the other side or fall back gracefully.

== now compares values, while is still asks whether both names refer to one object. Python derives != from __eq__ automatically, so you do not need to write it.

Sets and dict keys rely on __hash__, and the rule is that objects which are equal must have the same hash. So when you define __eq__ without __hash__, Python sets __hash__ to None and the class becomes unhashable. The class above cannot go into a set or be used as a dict key:

try:
    {a, b}
except TypeError as e:
    print(e)

Uses the Point with __eq__ but no __hash__

The fix is to add a __hash__ built from the same fields that __eq__ compares. Hashing a tuple of those fields is the usual way:

The built-in len(obj) simply calls obj.__len__(). Any class that defines it works with len(). As a bonus, Python uses __len__ for truth testing when there is no __bool__: an object whose length is 0 counts as false in an if.

Some values are best computed from other data instead of stored. A rectangle's area is always width times height, so keeping a separate area field means you must remember to update it whenever the size changes. The @property decorator solves this: you write an ordinary method, and Python lets callers read it as if it were a plain attribute, with no parentheses.

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    @property
    def area(self):
        return self.width * self.height

r = Rectangle(3, 4)
print(r.area)
r.width = 5
print(r.area)
try:
    r.area = 99
except AttributeError:
    print('area is read-only')

area is recomputed on every read, so it never goes stale

Two things happened here. Reading r.area ran the method and returned its result, and after width changed the next read gave the new answer. Trying to assign to r.area failed with AttributeError, because a property with only a getter has no way to accept a value. That is how you get a read-only attribute in Python.

A read-only property is only half the feature. If you also want assignments to be checked, add a method named the same as the property and decorate it with @name.setter. Python calls that method every time someone writes obj.name = value, so it is the right place to reject bad input by raising ValueError.

When the value is fine, the setter stores it. Where it stores it matters: the real data must live under a different name from the property, by convention the same name with a leading underscore. The property price is the public door, and self._price is the room behind it.

class Product:
    def __init__(self, name, price):
        self.name = name
        self.price = price  # goes through the setter

    @property
    def price(self):
        return self._price

    @price.setter
    def price(self, value):
        if value < 0:
            raise ValueError('price cannot be negative')
        self._price = value

p = Product('pen', 10)
p.price = 12
print(p.price)
try:
    p.price = -5
except ValueError as e:
    print('ValueError:', e)
try:
    Product('bad', -1)
except ValueError as e:
    print('ValueError:', e)
print(p.price)

the check also runs inside __init__, because it assigns through self.price

Notice that __init__ assigns to self.price, not self._price. That sends the starting value through the setter too, so an object can never be created with an invalid price. After the failed assignment, the old value of 12 is still there.

class Broken:
    def __init__(self, v):
        self.v = v

    @property
    def v(self):
        return self.v  # reads itself

    @v.setter
    def v(self, value):
        self.v = value  # assigns itself

try:
    Broken(1)
except RecursionError:
    print('RecursionError: setter called itself')

the fix is self._v in both the getter and the setter

Interviewers like this topic because it tests whether you understand Python's attitude to encapsulation. Java-style code writes getPrice() and setPrice() from day one. Python code starts with a plain attribute and upgrades it to a property only when logic is needed.

Many classes exist only to hold a few values. You write __init__ to store them, __repr__ so printing is readable, and __eq__ so two objects with the same values compare equal. That is the same code every time. The @dataclass decorator from the dataclasses module writes it for you.

It reads the annotated fields in the class body, in order, and builds the methods from them. A field with a value after it, like y: int = 0, becomes an optional argument. Only names with an annotation count as fields.

from dataclasses import dataclass

@dataclass
class Point:
    x: int
    y: int = 0

p = Point(3)
print(p)
print(p == Point(3, 0))
print(p is Point(3, 0))

__init__ takes x and y, __repr__ shows the fields, __eq__ compares them

The repr shows every field by name, so debugging output is useful for free. == compares the fields as a tuple, so two different objects with equal values are equal. is still asks whether they are the same object, and here they are not.

A default value in a class body is created once and shared. For an int or a string that is harmless, because you cannot change it in place. A list or dict is different: if every instance shared one list, appending to it in one object would change it in all of them. This is the same trap as mutable default arguments in functions.

Dataclasses refuse to let you fall into it. A plain tags: list = [] raises a ValueError the moment the class is defined, not later when the bug would show up.

from dataclasses import dataclass, field

try:
    @dataclass
    class Bad:
        tags: list = []
except ValueError as e:
    print(e)

The error happens at class creation

The fix is field(default_factory=list). Instead of one stored list, you give a factory, a function with no arguments that the generated __init__ calls each time an object is made without that argument. Every instance gets its own fresh list.

@dataclass
class Post:
    title: str
    tags: list[str] = field(default_factory=list)

a = Post('A')
b = Post('B')
a.tags.append('python')
print(a.tags, b.tags)

Each Post builds its own list

The decorator takes options. frozen=True makes instances immutable: assigning to a field afterwards raises FrozenInstanceError. Because eq is on and the fields can no longer change, Python also generates __hash__, so frozen instances can be dict keys or set members. A normal dataclass is not hashable, because it has __eq__ but its values can change.

order=True adds <, <=, > and >=. They compare the fields as tuples in the order you declared them, so put the most important field first.

@dataclass(frozen=True, order=True)
class Version:
    major: int
    minor: int

v1 = Version(1, 2)
v2 = Version(1, 10)
print(v1 < v2)
print(sorted([v2, v1]))
print({v1: 'old'}[Version(1, 2)])
try:
    v1.minor = 5
except Exception as e:
    print(type(e).__name__, e)

Comparison, sorting, use as a key, and blocked assignment

Note that 1.2 < 1.10 works here because the comparison is on the integer pair (1, 2) against (1, 10), not on text.

Once you know how to write a subclass, it is tempting to use inheritance every time two classes are related. A better habit is to ask what the relationship actually is. If one thing is a kind of another, inheritance fits. If one thing has another thing inside it, you want composition.

Here is a genuine is-a relationship. A Dog really is an Animal, so it inherits name and eat() and only adds what is special to dogs.

A car is not a kind of engine, so inheritance would be wrong there. With composition, the Car stores an Engine object as an attribute. When the car is asked to start, it delegates the real work to that object by calling self.engine.start().

class Engine:
    def __init__(self, hp):
        self.hp = hp

    def start(self):
        return f"Engine ({self.hp} hp) running"

class Car:
    def __init__(self, engine):
        self.engine = engine

    def start(self):
        return "Car: " + self.engine.start()

car = Car(Engine(120))
print(car.start())
print(isinstance(car, Engine))

The Car holds an Engine; it is not one.

The practical difference shows up when requirements change. Every level in an inheritance tree is tied to the level above it, so a change near the top can ripple down through every subclass. Consider a small tower where each class builds on its parent with super().

Now imagine you need an electric truck. It has no fuel to pump, but Truck inherits that step from MotorVehicle and cannot simply opt out. You end up overriding methods, adding flags, or rebuilding the tree. The subclass is coupled to every decision made above it.

Composition avoids this because the Car only knows that its engine has a start() method. Any object with that method will do, and since the engine is just an attribute, you can replace it while the program is running. This is the same car from the previous page.

class ElectricMotor:
    def start(self):
        return "Motor hums silently"

car.engine = ElectricMotor()
print(car.start())

Swapped at runtime, and Car itself did not change.

Interviewers often ask you to explain the rule "favor composition over inheritance". It does not mean inheritance is bad. It means that when both options would work, composition is usually the safer default, because it creates fewer hidden dependencies.

A classic misuse is a Stack that inherits from list just to reuse append and pop. A stack is not a list, because a stack must only allow changes at one end. The inherited class still exposes insert, so anyone can break the rule. The composed version hides the list and exposes only what a stack should offer.

Most beginner bugs in Python classes come from a few repeated slips. The first is the easiest to make: leaving self out of a method definition. When you call obj.method(), Python quietly passes the object as the first argument. If the method has no parameter to receive it, the call fails before your code even runs.

class Dog:
    def bark():
        return "Woof"

try:
    Dog().bark()
except TypeError as e:
    print(e)

The method takes zero parameters, but Python passes one

The message is confusing because you passed no arguments. The one that was "given" is the instance itself. The fix is to add self as the first parameter, and to use self.name whenever the method needs data stored on the object.

class Dog:
    def bark(self):
        return "Woof"

print(Dog().bark())

With self, the instance has somewhere to land

The second trap is a default value that is a list, dict or set. Python builds a default once, when the def line runs, not each time you call the function. Every call that skips the argument receives that same object, so one instance can change what another instance sees.

class Basket:
    def __init__(self, items=[]):
        self.items = items

    def add(self, x):
        self.items.append(x)

a = Basket()
b = Basket()
a.add("apple")
print(b.items)
print(a.items is b.items)
print(Basket.__init__.__defaults__)

b never received an apple, yet it has one

The last line shows where the list lives: inside the function's __defaults__, shared by every call. The standard fix is to use None as the default and create a fresh list inside the body.

class Basket:
    def __init__(self, items=None):
        self.items = [] if items is None else list(items)

    def add(self, x):
        self.items.append(x)

a = Basket()
b = Basket()
a.add("apple")
print(b.items)
print(a.items is b.items)

A new list is built on every call

The same sharing problem appears with class attributes. A list written directly in the class body belongs to the class, and every instance reads it through the class unless it has its own attribute of the same name. Mutating it with append changes the one shared object.

class Player:
    tags = []

    def __init__(self, name):
        self.name = name

p1 = Player("Ana")
p2 = Player("Bo")
p1.tags.append("admin")
print(p2.tags)
print(Player.tags is p2.tags)

One list on the class, seen by everyone

Per-object data belongs in __init__, assigned to self. Keep class attributes for values that really are shared and are not changed in place, such as constants or counters you update on the class itself.

class Player:
    def __init__(self, name):
        self.name = name
        self.tags = []

p1, p2 = Player("Ana"), Player("Bo")
p1.tags.append("admin")
print(p2.tags)

Each player now owns its list

When a child class defines its own __init__, it replaces the parent's one completely. The parent's setup code never runs unless you call it, so attributes the parent would have created simply do not exist.

class Animal:
    def __init__(self, name):
        self.name = name

class Cat(Animal):
    def __init__(self, name, indoor):
        self.indoor = indoor

c = Cat("Tom", True)
try:
    print(c.name)
except AttributeError as e:
    print(e)

Animal.__init__ was never called

class Cat(Animal):
    def __init__(self, name, indoor):
        super().__init__(name)
        self.indoor = indoor

c = Cat("Tom", True)
print(c.name, c.indoor)

Call the parent first, then add your own attributes

Another common mistake is writing a class that has no real state or behaviour to bundle. If a class has only __init__ and one method, a plain function is shorter. If it only holds a few fields, a dataclass writes the boilerplate for you.

from dataclasses import dataclass

def apply_tax(price, rate):
    return round(price * (1 + rate), 2)

@dataclass
class Point:
    x: int
    y: int

print(apply_tax(100, 0.18))
print(Point(1, 2))

A function for an action, a dataclass for plain data

Interviewers like these mistakes because each one tests whether you understand when Python runs things. Here are the three questions that come up most often, with answers you can say out loud.

class Cart:
    def __init__(self):
        self.items = []

c = Cart()
print(vars(c))
print(hasattr(c, "total"))
try:
    c.total
except AttributeError as e:
    print(e)

vars() shows exactly which attributes exist

Almost every Python class is built from the same few pieces. The table below lists each one with what it does, so you can use it as a lookup when you are writing or reading a class.

The program below uses most of these pieces together. Puppy inherits from Animal, calls super().__init__() to set the name, and keeps its age behind a @property whose setter rejects negative values. @dataclass is the one piece not shown here, because the class below is not plain data: it has behavior and a rule to enforce.

class Animal:
    def __init__(self, name):
        self.name = name

class Puppy(Animal):
    def __init__(self, name, toy):
        super().__init__(name)
        self.toy = toy
        self._age = 1

    @property
    def age(self):
        return self._age

    @age.setter
    def age(self, value):
        if value < 0:
            raise ValueError('age cannot be negative')
        self._age = value

    def speak(self):
        return f'{self.name} says woof'

p = Puppy('Rex', 'ball')
print(p.speak())
print(p.age, p.toy)
try:
    p.age = -1
except ValueError as e:
    print('error:', e)

Inheritance, super() and a validating property in one class

Dunder methods (short for double underscore) are hooks Python calls for you when an object meets built-in syntax. You rarely call them directly. Instead, print(obj) calls __str__, obj == other calls __eq__, and so on. The five below cover most day-to-day needs.

Hashing deserves a closer look. Sets and dict keys find items by hash first and then confirm with ==. That is why the two methods must agree: if two objects are equal, they must produce the same hash. In the example below, two separate Box objects with the same contents are equal, hash the same, and collapse into one set entry.

class Box:
    def __init__(self, items):
        self.items = list(items)

    def __repr__(self):
        return f'Box({self.items!r})'

    def __str__(self):
        return f'a box with {len(self.items)} items'

    def __eq__(self, other):
        return isinstance(other, Box) and self.items == other.items

    def __len__(self):
        return len(self.items)

    def __hash__(self):
        return hash(tuple(self.items))

a = Box([1, 2])
b = Box([1, 2])
print(repr(a))
print(a)
print(a == b)
print(len(a))
print(len({a, b}))

All five dunders on one small class

Most design choices in Python OOP come down to four short rules. Match your situation to the left column and use the tool on the right.

Try to answer each question in your head before you open the answer. They ask you to predict what Python does or to find the bug, so you can't pass by remembering wording.

• A class is a blueprint and an object too. An instance is one object built from it, with its own __dict__.
• self is just the first parameter, and d.bark() is sugar for Dog.bark(d). State only sticks if you assign it with self.name = name.
• Lookup goes instance, then class, then parents. Assigning through an instance shadows the class attribute, and a mutable class attribute is shared by all instances.
• Call super().__init__() in subclasses. super() follows the MRO, so it is not always the direct parent.
• Define __repr__ for debugging and __eq__ for ==. If you define __eq__, define __hash__ too, or the class becomes unhashable.
• Use @property for validation and read-only values with a _name backing field, and @dataclass for plain data with default_factory for mutable defaults.
• Inherit for is-a, compose for has-a, and never use a mutable default argument.