Python Classes Practice: self, super(), __repr__ vs __str__, inheritance

Every instance method receives the instance as its first argument. By convention, we call it self:

class Dog:
    def bark(self):
        return f"{self.name} barks!"

fido = Dog()
fido.name = "Fido"
fido.bark()  # Python calls Dog.bark(fido)

When you call fido.bark(), Python translates it to Dog.bark(fido). That's why methods need self—it's how they access the instance.

The classic error

If you forget self in the signature or call a method on the class instead of an instance:

# Missing self in definition
class Bad:
    def greet():  # Bug: no self
        return "Hello"

Bad().greet()  # TypeError: greet() takes 0 positional arguments but 1 was given

# Calling on class instead of instance
class Dog:
    def bark(self):
        return "Woof!"

Dog.bark()  # TypeError: missing 1 required positional argument: 'self'

Fix: Always include self as the first parameter, and call methods on instances, not classes.

This is one of the most common Python OOP bugs:

class Team:
    members = []  # Class attribute—shared!

    def add(self, name):
        self.members.append(name)

alpha = Team()
beta = Team()
alpha.add("Alice")
print(beta.members)  # ['Alice'] — wait, what?

Why it happens: members = [] creates ONE list at class definition time. All instances share that same list object.

The fix: Initialize mutable attributes in __init__:

class Team:
    def __init__(self):
        self.members = []  # Instance attribute—each instance gets its own

alpha = Team()
beta = Team()
alpha.add("Alice")
print(beta.members)  # [] — correct!

Rule of thumb:

• Class attributes for shared constants: species = "dog"
• Instance attributes for per-instance state: self.name = name

When you override __init__ in a subclass, the parent's __init__ doesn't run automatically:

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

class Dog(Animal):
    def __init__(self, name, breed):
        # If we forget to call super().__init__(), self.name won't exist!
        self.breed = breed

fido = Dog("Fido", "Lab")
print(fido.name)  # AttributeError: 'Dog' object has no attribute 'name'

Always call the parent's __init__:

class Dog(Animal):
    def __init__(self, name, breed):
        super().__init__(name)  # Runs Animal.__init__
        self.breed = breed

fido = Dog("Fido", "Lab")
print(fido.name)  # "Fido" — works!

Why super() instead of Parent.init()?

super() follows the Method Resolution Order (MRO), which matters for multiple inheritance. Direct parent calls can break in diamond inheritance patterns.

Inheritance (is-a): Use when the subclass truly IS a specialized version of the parent.

class Animal:
    def eat(self):
        print("Eating...")

class Dog(Animal):  # A Dog IS an Animal
    def bark(self):
        print("Woof!")

Composition (has-a): Use when one class USES another but isn't a subtype.

class Engine:
    def start(self):
        print("Vroom!")

class Car:
    def __init__(self):
        self.engine = Engine()  # A Car HAS an Engine

    def start(self):
        self.engine.start()

Prefer composition when you're unsure. It's more flexible:

• You can swap implementations (dependency injection) — this is the core idea behind the Strategy pattern
• You avoid inheriting methods you don't want
• You can compose multiple behaviors without multiple inheritance complexity

Both methods convert objects to strings, but they serve different audiences:

If you only implement one, implement __repr__. Python uses it as a fallback when __str__ is missing.

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

    def __repr__(self):
        # Unambiguous: could be used to recreate the object
        return f"Point({self.x!r}, {self.y!r})"

    def __str__(self):
        # Readable: for end users
        return f"({self.x}, {self.y})"

p = Point(3, 4)
print(repr(p))  # Point(3, 4)  — for devs
print(str(p))   # (3, 4)       — for users
print(p)        # (3, 4)       — print() uses __str__

In the REPL

>>> p = Point(3, 4)
>>> p           # Uses __repr__
Point(3, 4)
>>> print(p)    # Uses __str__
(3, 4)

The !r format spec: f"{self.x!r}" calls repr() on self.x, ensuring strings show with quotes.

Dunder (double underscore) methods let your objects work with Python syntax:

Example: equality comparison

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

    def __eq__(self, other):
        if not isinstance(other, Point):
            return NotImplemented  # Let Python try other.__eq__
        return self.x == other.x and self.y == other.y

Point(1, 2) == Point(1, 2)  # True (compares values)

Without __eq__, == compares identity (same object in memory), not value. When your objects need to notify others about state changes, the Observer pattern provides a clean structure for event-driven communication.

Use @property to add getters/setters with validation:

class Circle:
    def __init__(self, radius):
        self.radius = radius  # Uses the setter

    @property
    def radius(self):
        return self._radius

    @radius.setter
    def radius(self, value):
        if value <= 0:
            raise ValueError("Radius must be positive")
        self._radius = value

c = Circle(5)
c.radius = -1  # ValueError: Radius must be positive

Note: The underlying data is stored in _radius (with underscore). The radius property provides the public interface. See the decorators page for more on how @property works.

If your class is primarily a data container, @dataclass eliminates boilerplate:

# Without dataclass: manual __init__, __repr__, __eq__
class Point:
    def __init__(self, x, y):
        self.x = x
        self.y = y

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

    def __eq__(self, other):
        return self.x == other.x and self.y == other.y

# With dataclass: all generated automatically
from dataclasses import dataclass

@dataclass
class Point:
    x: float
    y: float

Use @dataclass when:

• You just need to store data with some methods
• Default __init__, __repr__, __eq__ are sufficient

Use a regular class when:

• You need complex initialization logic
• You want full control over attribute storage
• You're modeling behavior-heavy objects, not data — the Factory pattern is useful when object creation itself is complex

For a printable reference of class syntax, see the Python OOP cheat sheet.

# Method signature (always include self)
def method(self, arg1, arg2):

# Call parent __init__
super().__init__(arg1, arg2)

# Instance attribute (in __init__)
self.name = name

# Class attribute (shared—careful with mutables!)
class Foo:
    class_attr = "shared"

# __repr__ for developers
def __repr__(self):
    return f"ClassName({self.attr!r})"

# __str__ for users
def __str__(self):
    return f"Human-readable: {self.attr}"

# Property with validation
@property
def x(self):
    return self._x

@x.setter
def x(self, value):
    if not valid(value):
        raise ValueError(...)
    self._x = value

• Python Tutorial: Classes
• Python Data Model: Special Method Names
• Real Python: repr vs str
• PEP 557 – Data Classes
• Python Tutorial: Inheritance