← OOP: Classes & Objects

Select a question from the sidebar

20 questions in this topic

Question 1 / 20

How do you define a class in Python, and what is the role of `init`?

A class in Python is defined using the class keyword. The __init__ method is the initializer (often called the constructor, though technically __new__ is the true constructor). It is called automatically when a new instance is created, and its primary purpose is to set up the instance's initial state by assigning attributes.

The first parameter of __init__ is always self, which refers to the newly created instance. Through self, you attach attributes that are unique to each instance.

Key distinctions:

__new__ creates the instance (allocates memory)
__init__ initializes the instance (sets attributes)
__init__ must return None (implicitly)
If __init__ is not defined, instances are created with no custom initialization

Pseudo Code

1. Use 'class ClassName:' to define a class
2. Define __init__(self, params) to initialize attributes
3. Use self.attribute = value to set instance attributes
4. Create instance: obj = ClassName(args)
5. Python calls __new__ then __init__ automatically

Code

class Dog:
    # Class attribute -- shared by all instances
    species = "Canis familiaris"

    def __init__(self, name, age, breed):
        """Initialize a Dog instance."""
        # Instance attributes -- unique to each instance
        self.name = name
        self.age = age
        self.breed = breed
        self.tricks = []  # mutable default per instance

    def bark(self):
        return f"{self.name} says Woof!"

    def learn_trick(self, trick):
        self.tricks.append(trick)
        return f"{self.name} learned {trick}"

# Creating instances
rex = Dog("Rex", 3, "German Shepherd")
buddy = Dog("Buddy", 5, "Golden Retriever")

print(rex.bark())        # Rex says Woof!
print(buddy.bark())      # Buddy says Woof!
print(rex.species)       # Canis familiaris (class attribute)

# Each instance has its own tricks list
rex.learn_trick("sit")
print(rex.tricks)    # ['sit']
print(buddy.tricks)  # [] -- separate list

# Instance attributes vs class attributes
print(rex.__dict__)  # {'name': 'Rex', 'age': 3, 'breed': 'German Shepherd', 'tricks': ['sit']}
print(Dog.__dict__)  # includes 'species', '__init__', 'bark', etc.

# What happens without __init__
class Empty:
    pass

e = Empty()
e.x = 10  # attributes can still be added dynamically
print(e.x)  # 10

Rex says Woof!
Buddy says Woof!
Canis familiaris
['sit']
[]
{'name': 'Rex', 'age': 3, 'breed': 'German Shepherd', 'tricks': ['sit']}
{'__module__': '__main__', 'species': 'Canis familiaris', '__init__': <function Dog.__init__ at <address>>, 'bark': <function Dog.bark at <address>>, 'learn_trick': <function Dog.learn_trick at <address>>, '__dict__': <attribute '__dict__' of 'Dog' objects>, '__weakref__': <attribute '__weakref__' of 'Dog' objects>, '__doc__': None}
10

Key Points

•__init__ initializes instance attributes via self.attr = value
•self refers to the current instance being created
•Class attributes are shared, instance attributes are per-instance
•__init__ is called automatically after __new__ creates the instance

Gotchas

•__init__ must return None -- returning anything else raises TypeError
•Mutable default arguments in __init__ signature (def __init__(self, items=[])) are shared across calls -- use None and create inside
•Forgetting self in __init__ creates a local variable, not an instance attribute

__init__ is the initializer called when creating an instance. It sets up instance attributes via self.attr = value. self refers to the new instance.

•__init__ sets up instance state, called automatically on creation
•self is the instance reference

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def greet(self):
        return f"Hi, I'm {self.name}, age {self.age}"

p = Person("Alice", 30)
print(p.greet())  # Hi, I'm Alice, age 30

Hi, I'm Alice, age 30

Returning a value from __init__ raises TypeError

Question 2 / 20

What is the difference between instance variables and class variables in Python?

Class variables are defined directly in the class body (outside any method). They are shared by all instances and belong to the class itself. Accessed via ClassName.var or instance.var (if no instance attribute shadows it).

Instance variables are defined inside methods (typically __init__) using self.var = value. Each instance gets its own copy.

The lookup order is: instance __dict__ first, then class __dict__, then base classes (MRO). When you assign self.var = value, it always creates/updates an instance variable, even if a class variable with the same name exists. This is called shadowing.

Mutable class variables are a common source of bugs: if you mutate (not reassign) a mutable class variable through an instance, all instances see the change because they share the same object.

Pseudo Code

1. Class variable: defined at class level, shared by all instances
2. Instance variable: defined via self.x = value, unique per instance
3. Lookup: instance.__dict__ -> class.__dict__ -> base classes
4. Assignment via self always creates/updates instance variable
5. Mutation of mutable class variable affects all instances

Code

class Student:
    # Class variables
    school = "MIT"
    all_students = []  # DANGER: mutable class variable

    def __init__(self, name, gpa):
        # Instance variables
        self.name = name
        self.gpa = gpa
        Student.all_students.append(self)  # modify class var via class name

# Class variable is shared
s1 = Student("Alice", 3.8)
s2 = Student("Bob", 3.5)

print(s1.school)  # MIT
print(s2.school)  # MIT
print(s1.school is s2.school)  # True -- same object

# Reassignment via instance creates instance variable (shadows class var)
s1.school = "Stanford"
print(s1.school)  # Stanford (instance variable)
print(s2.school)  # MIT (still class variable)
print(Student.school)  # MIT (class variable unchanged)

print("school" in s1.__dict__)  # True -- s1 has instance var
print("school" in s2.__dict__)  # False -- s2 uses class var

# Mutable class variable pitfall
print(Student.all_students)  # [<Student Alice>, <Student Bob>]
print(len(s1.all_students))  # 2 -- shared between all instances

# Demonstrating the pitfall with mutable defaults
class BrokenList:
    items = []  # shared mutable class variable

    def add(self, item):
        self.items.append(item)  # mutates the CLASS variable!

a = BrokenList()
b = BrokenList()
a.add("x")
print(b.items)  # ['x'] -- oops, shared!

# Fixed version
class FixedList:
    def __init__(self):
        self.items = []  # instance variable -- each gets its own

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

a = FixedList()
b = FixedList()
a.add("x")
print(b.items)  # [] -- correctly isolated

MIT
MIT
True
Stanford
MIT
MIT
True
False
[<__main__.Student object at <address>>, <__main__.Student object at <address>>]
2
['x']
[]

Key Points

•Class variables are shared across all instances, defined at class level
•Instance variables are unique per instance, defined via self.x in __init__
•Assignment via self creates an instance variable that shadows the class variable
•Lookup order: instance -> class -> base classes

Gotchas

•Mutable class variables (lists, dicts) are shared -- mutating one affects all instances
•self.var = value always creates an instance variable, even if a class variable exists with that name
•del instance.var removes the instance variable, re-exposing the class variable

Class variables are defined at class level and shared by all instances. Instance variables are set via self.x in __init__ and are unique per instance. Assignment via self creates an instance variable that shadows the class variable.

•Class variables shared, instance variables unique
•self.x = v creates instance variable, ClassName.x = v modifies class variable

class Counter:
    count = 0  # class variable (shared)

    def __init__(self, name):
        self.name = name  # instance variable (unique)
        Counter.count += 1

a = Counter("a")
b = Counter("b")
print(Counter.count)  # 2 (shared)
print(a.name)  # 'a' (unique)

2
a

Mutable class variables (lists, dicts) shared across instances cause bugs

Question 3 / 20

What is the difference between instance methods, class methods, and static methods?

Python classes support three types of methods, each receiving different first arguments:

Instance methods: Regular methods that receive self (the instance) as the first argument. They can access and modify both instance and class state. This is the default method type.

Class methods (@classmethod): Receive cls (the class) as the first argument. They can access and modify class state but not instance state. Used for alternative constructors and class-level operations.

Static methods (@staticmethod): Receive no implicit first argument. They are essentially regular functions namespaced within the class. They cannot access instance or class state directly.

All three can be called on both the class and instances, but instance methods require an instance.

Pseudo Code

Instance method: def method(self) -> access instance + class state
Class method: @classmethod def method(cls) -> access class state only
Static method: @staticmethod def method() -> no access to class/instance state

Call patterns:
- instance.method() works for all three
- Class.method() works for classmethod and staticmethod
- Class.instance_method() requires passing instance manually

Code

class Pizza:
    base_price = 10.0  # class variable

    def __init__(self, toppings, size="medium"):
        self.toppings = toppings  # instance variable
        self.size = size

    # Instance method -- accesses self (instance)
    def price(self):
        topping_cost = len(self.toppings) * 1.5
        size_multiplier = {"small": 0.8, "medium": 1.0, "large": 1.3}
        return (self.base_price + topping_cost) * size_multiplier[self.size]

    # Class method -- accesses cls (class), used as alternative constructor
    @classmethod
    def margherita(cls):
        """Factory method for a standard margherita."""
        return cls(["mozzarella", "tomato", "basil"], "medium")

    @classmethod
    def set_base_price(cls, price):
        """Modify class state."""
        cls.base_price = price

    # Static method -- no access to instance or class
    @staticmethod
    def validate_topping(topping):
        valid = {"mozzarella", "tomato", "basil", "pepperoni", "mushroom"}
        return topping.lower() in valid

# Instance method -- needs an instance
p = Pizza(["pepperoni", "mushroom"], "large")
print(p.price())  # (10.0 + 3.0) * 1.3 = 16.9

# Class method -- called on class or instance
m = Pizza.margherita()  # alternative constructor
print(m.toppings)  # ['mozzarella', 'tomato', 'basil']
print(type(m))     # <class 'Pizza'>

# Static method -- called on class or instance
print(Pizza.validate_topping("pepperoni"))  # True
print(p.validate_topping("pineapple"))      # False

# Key difference: inheritance behavior
class FancyPizza(Pizza):
    base_price = 15.0

f = FancyPizza.margherita()  # cls is FancyPizza
print(type(f))      # <class 'FancyPizza'> -- classmethod used cls
print(f.base_price) # 15.0

16.900000000000002
['mozzarella', 'tomato', 'basil']
<class '__main__.Pizza'>
True
False
<class '__main__.FancyPizza'>
15.0

Key Points

•Instance methods: receive self, access all state
•Class methods: receive cls, access class state, used as alternative constructors
•Static methods: no implicit arg, utility functions namespaced in class
•Class methods respect inheritance (cls is the actual subclass)

Gotchas

•Calling an instance method on the class requires passing the instance: Class.method(instance)
•Static methods cannot access self or cls -- if you need either, use the appropriate method type
•In a classmethod, use cls() not ClassName() to support subclass inheritance

Instance methods get self, class methods get cls, static methods get nothing implicit. Use instance methods for per-object behavior, class methods for constructors, static methods for utilities.

•self for instance, cls for class, nothing for static
•classmethod for alt constructors, staticmethod for utilities

class MyClass:
    x = 10
    def instance_method(self):    return self.x

    @classmethod
    def class_method(cls):        return cls.x

    @staticmethod
    def static_method():          return "no access to self or cls"

obj = MyClass()
print(obj.instance_method())  # 10
print(MyClass.class_method()) # 10
print(MyClass.static_method())  # no access to self or cls

10
10
no access to self or cls

Calling instance method on class requires passing instance manually

Question 4 / 20

How does `self` work in Python, and why is it explicitly required?

self is the conventional name for the first parameter of instance methods. It refers to the instance on which the method is called. Python requires it explicitly (unlike this in Java/C++ which is implicit) following the Zen of Python's principle: "Explicit is better than implicit."

When you call obj.method(arg), Python translates it to ClassName.method(obj, arg). The instance is automatically passed as the first argument. self is not a keyword -- you could name it anything, but self is a universally followed convention.

The explicit self serves several purposes:

Makes it clear when you're accessing instance attributes vs local variables
Allows methods to be defined outside the class and attached later
Makes the descriptor protocol and method binding transparent

Pseudo Code

1. obj.method(arg) is equivalent to ClassName.method(obj, arg)
2. self is just the first parameter -- by convention named 'self'
3. self.x accesses instance attribute x
4. x alone accesses local variable x
5. Without self prefix, you'd confuse instance vs local variables

Code

class Rectangle:
    def __init__(self, width, height):
        # self.width is instance attribute, width is the parameter
        self.width = width
        self.height = height

    def area(self):
        # self.width accesses instance attribute
        return self.width * self.height

    def resize(self, factor):
        self.width *= factor
        self.height *= factor
        return self  # returning self enables method chaining

r = Rectangle(10, 5)

# These are equivalent:
print(r.area())              # 50 -- Python passes r as self
print(Rectangle.area(r))     # 50 -- explicit unbound call

# Method chaining with return self
r.resize(2).resize(0.5)
print(r.area())  # 50 -- back to original

# self is not a keyword -- any name works (but DON'T do this)
class BadStyle:
    def __init__(this, value):  # works but violates convention
        this.value = value

# Why explicit self matters: methods can be defined outside
def external_greet(self):
    return f"Hello from {self.name}"

class Person:
    def __init__(self, name):
        self.name = name
    greet = external_greet  # attach external function as method

p = Person("Alice")
print(p.greet())  # Hello from Alice

# Common mistake: forgetting self
class Broken:
    def __init__(self, x):
        x = x  # BUG: this sets local var, not instance attribute
        # Should be: self.x = x

50
50
50.0
Hello from Alice

Key Points

•self is the instance passed as the first argument to instance methods
•obj.method(arg) translates to Class.method(obj, arg)
•self is a convention, not a keyword, but always use the name self
•Explicit self distinguishes instance attributes from local variables

Gotchas

•Forgetting self.x = x in __init__ creates a local variable instead of instance attribute
•Forgetting self as the first parameter causes TypeError: method takes 0 positional arguments but 1 was given
•Using a name other than self works but violates PEP 8 conventions

self is the first parameter of instance methods, referring to the instance. obj.method() automatically passes obj as self. It is explicit to distinguish instance attributes from locals.

•self = the instance, passed automatically by Python
•Explicit to distinguish self.x (instance) from x (local)

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

    def bark(self):
        return f"{self.name} says Woof!"

dog = Dog("Rex")
print(dog.bark())          # Rex says Woof!
print(Dog.bark(dog))       # Rex says Woof! -- equivalent

Rex says Woof!
Rex says Woof!

Forgetting self in method definition causes TypeError when calling

Question 5 / 20

How does the `@property` decorator work for encapsulation in Python classes?

The @property decorator provides a Pythonic way to implement encapsulation by defining getter, setter, and deleter methods that are accessed like regular attributes. This follows the Uniform Access Principle -- the caller doesn't need to know whether they're accessing a stored attribute or a computed value.

The property mechanism allows you to:

Add validation on setting values
Compute values on the fly (lazy/computed properties)
Make attributes read-only by omitting the setter
Migrate from simple attributes to properties without breaking the public API

This is preferable to Java-style get_x()/set_x() methods because Python's philosophy favors direct attribute access when possible, with properties as a seamless upgrade path when control is needed.

Pseudo Code

1. Define getter with @property -- read access
2. Define setter with @name.setter -- write access with validation
3. Define deleter with @name.deleter -- delete with cleanup
4. Store actual value in private attribute (self._name)
5. External code uses obj.name as if it were a simple attribute

Code

class BankAccount:
    def __init__(self, owner, balance=0):
        self.owner = owner
        self._balance = balance  # private by convention
        self._transactions = []

    @property
    def balance(self):
        """Read-only computed from transactions."""
        return self._balance

    @balance.setter
    def balance(self, value):
        if value < 0:
            raise ValueError("Balance cannot be negative")
        self._balance = value

    @property
    def is_overdrawn(self):
        """Computed property -- no setter means read-only."""
        return self._balance < 0

    def deposit(self, amount):
        if amount <= 0:
            raise ValueError("Deposit must be positive")
        self._balance += amount
        self._transactions.append(("deposit", amount))

    def withdraw(self, amount):
        if amount > self._balance:
            raise ValueError("Insufficient funds")
        self._balance -= amount
        self._transactions.append(("withdraw", amount))

account = BankAccount("Alice", 1000)
print(account.balance)      # 1000 -- calls getter
account.deposit(500)
print(account.balance)      # 1500
print(account.is_overdrawn) # False -- computed property

try:
    account.balance = -100  # calls setter, raises ValueError
except ValueError as e:
    print(e)  # Balance cannot be negative

try:
    account.is_overdrawn = True  # AttributeError -- no setter
except AttributeError as e:
    print(e)  # property 'is_overdrawn' ... has no setter

# Migrating from plain attribute to property (no API change)
class Circle:
    def __init__(self, radius):
        self._radius = radius

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

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

    @property
    def area(self):
        import math
        return math.pi * self._radius ** 2

c = Circle(5)
print(c.radius)  # 5
print(c.area)    # 78.539...
c.radius = 10    # validation via setter
print(c.area)    # 314.159...

1000
1500
False
Balance cannot be negative
property 'is_overdrawn' of 'BankAccount' object has no setter
5
78.53981633974483
314.1592653589793

Key Points

•@property provides getter, @name.setter provides validated setter
•Omitting setter makes the property read-only
•Properties allow migration from plain attributes without changing API
•Store backing data in _private attribute to avoid recursion

Gotchas

•Using self.name = value inside the setter when name is the property causes infinite recursion
•Properties are defined on the class, not the instance -- they must be class-level
•Properties add method call overhead compared to direct attribute access

@property creates attribute-style access with getter/setter control. Use @name.setter for validation. Omit setter for read-only. Store data in self._name to avoid recursion.

•@property for getter, @name.setter for validated setter
•Use _private backing attribute

class User:
    def __init__(self, age):
        self._age = age

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

    @age.setter
    def age(self, value):
        if value < 0:
            raise ValueError("Age must be non-negative")
        self._age = value

u = User(25)
u.age = 30   # validated
print(u.age) # 30

Assigning self.name inside setter causes infinite recursion

Question 6 / 20

What is `slots` and when should you use it?

__slots__ is a class attribute that explicitly declares the allowed instance attributes. When defined, Python does not create a __dict__ for each instance, instead allocating a fixed set of slots for the declared attributes.

Benefits:

Memory savings: No per-instance __dict__ -- significant when creating millions of instances
Faster attribute access: Slot access uses a fixed offset rather than a hash table lookup
Prevents typos: Assigning to an undeclared attribute raises AttributeError

Drawbacks:

Cannot add attributes dynamically
Cannot use multiple inheritance with different non-empty __slots__
Weakref not supported unless __weakref__ is in __slots__
Must re-declare slots in subclasses (they don't inherit)

__slots__ is most useful for data-heavy classes with many instances (e.g., ORM rows, data points, game objects).

Pseudo Code

1. Define __slots__ = ('attr1', 'attr2') at class level
2. No __dict__ is created for instances
3. Only declared attributes can be set
4. Saves ~50-60% memory per instance
5. Attribute access is slightly faster (direct offset vs dict lookup)

Code

import sys

# Without __slots__
class PointDict:
    def __init__(self, x, y):
        self.x = x
        self.y = y

# With __slots__
class PointSlots:
    __slots__ = ('x', 'y')

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

# Memory comparison
p_dict = PointDict(1, 2)
p_slots = PointSlots(1, 2)

print(sys.getsizeof(p_dict) + sys.getsizeof(p_dict.__dict__))
# ~152 bytes (instance + __dict__)
print(sys.getsizeof(p_slots))
# ~56 bytes (no __dict__)

# No __dict__ with __slots__
print(hasattr(p_dict, '__dict__'))   # True
print(hasattr(p_slots, '__dict__'))  # False

# Dynamic attribute assignment prevented
try:
    p_slots.z = 3  # AttributeError!
except AttributeError as e:
    print(e)  # 'PointSlots' object has no attribute 'z'

# Slots with inheritance
class Point3D(PointSlots):
    __slots__ = ('z',)  # only add NEW attributes

    def __init__(self, x, y, z):
        super().__init__(x, y)
        self.z = z

p3d = Point3D(1, 2, 3)
print(p3d.x, p3d.y, p3d.z)  # 1 2 3
print(hasattr(p3d, '__dict__'))  # False

# To allow __dict__ alongside slots:
class Flexible:
    __slots__ = ('x', '__dict__')  # allows dynamic attrs too

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

f = Flexible(10)
f.y = 20  # works because __dict__ is in __slots__
print(f.x, f.y)  # 10 20

344
48
True
False
'PointSlots' object has no attribute 'z'
1 2 3
False
10 20

Key Points

•__slots__ prevents __dict__ creation, saving memory
•Only declared attributes can be assigned
•Faster attribute access via fixed-offset slots
•Must re-declare in subclasses -- only add new attributes

Gotchas

•Cannot add attributes not in __slots__ -- raises AttributeError
•Subclasses without __slots__ get __dict__ back, negating memory savings
•Cannot use __slots__ with multiple inheritance if both parents have non-empty __slots__
•weakref requires '__weakref__' in __slots__

__slots__ declares allowed instance attributes, preventing __dict__ creation. Saves memory and speeds up access. Use when creating many instances with fixed attributes.

•Prevents __dict__, saves 50%+ memory per instance
•Only declared attributes allowed

class Point:
    __slots__ = ('x', 'y')

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

p = Point(1, 2)
print(p.x, p.y)  # 1 2
# p.z = 3  # AttributeError -- not in __slots__

1 2

Cannot add dynamic attributes unless __dict__ is in __slots__

Question 7 / 20

How do dataclasses work in Python, and when should you use them?

The @dataclass decorator (from dataclasses module, Python 3.7+) automatically generates boilerplate methods like __init__, __repr__, __eq__, and optionally __hash__, __lt__, etc., based on class annotations.

Dataclasses are ideal for classes that primarily store data (DTOs, configuration objects, records). They reduce boilerplate while remaining regular classes -- you can still add methods, use inheritance, and customize behavior.

Key parameters of @dataclass:

frozen=True: makes instances immutable (also enables hashing)
order=True: generates comparison methods (__lt__, __le__, etc.)
slots=True (Python 3.10+): generates __slots__
kw_only=True (Python 3.10+): makes all fields keyword-only

Use field() for advanced field configuration: default factories, excluding from repr/compare, etc.

Pseudo Code

1. Import dataclass and field from dataclasses
2. Apply @dataclass decorator to class
3. Define fields as class annotations with optional defaults
4. __init__, __repr__, __eq__ are auto-generated
5. Use field(default_factory=list) for mutable defaults
6. Use __post_init__ for validation or computed fields

Code

from dataclasses import dataclass, field
from typing import List

@dataclass
class Product:
    name: str
    price: float
    quantity: int = 0
    tags: List[str] = field(default_factory=list)  # mutable default

    @property
    def total_value(self):
        return self.price * self.quantity

# Auto-generated __init__, __repr__, __eq__
p1 = Product("Widget", 9.99, 100, ["sale"])
p2 = Product("Widget", 9.99, 100, ["sale"])

print(p1)          # Product(name='Widget', price=9.99, quantity=100, tags=['sale'])
print(p1 == p2)    # True (auto __eq__ compares all fields)
print(p1.total_value)  # 999.0

# Frozen dataclass (immutable)
@dataclass(frozen=True)
class Point:
    x: float
    y: float

pt = Point(1.0, 2.0)
try:
    pt.x = 3.0  # FrozenInstanceError
except Exception as e:
    print(type(e).__name__)  # FrozenInstanceError

# Frozen dataclasses are hashable (can be dict keys / set members)
points = {Point(0, 0), Point(1, 1), Point(0, 0)}
print(len(points))  # 2 -- duplicate removed

# __post_init__ for validation
@dataclass
class Employee:
    name: str
    salary: float
    department: str = "Engineering"
    email: str = field(init=False)  # not in __init__

    def __post_init__(self):
        if self.salary < 0:
            raise ValueError("Salary cannot be negative")
        self.email = f"{self.name.lower().replace(' ', '.')}@company.com"

emp = Employee("Alice Smith", 85000)
print(emp.email)  # alice.smith@company.com

# Python 3.10+ features
@dataclass(slots=True, frozen=True)
class Config:
    host: str = "localhost"
    port: int = 8080
    debug: bool = False

Product(name='Widget', price=9.99, quantity=100, tags=['sale'])
True
999.0
FrozenInstanceError
2
alice.smith@company.com

Key Points

•@dataclass auto-generates __init__, __repr__, __eq__
•Use field(default_factory=list) for mutable defaults
•frozen=True makes instances immutable and hashable
•__post_init__ runs after __init__ for validation and computed fields

Gotchas

•Never use mutable default values directly (tags: list = []) -- use field(default_factory=list)
•Fields with defaults must come after fields without defaults (like function args)
•@dataclass(eq=True) is default, but __hash__ is set to None unless frozen=True
•Inheritance: parent fields come first in __init__, child fields after

@dataclass auto-generates __init__, __repr__, __eq__ from annotated fields. Use field(default_factory=list) for mutable defaults, frozen=True for immutability, and __post_init__ for validation.

•Auto-generates __init__, __repr__, __eq__
•Use field(default_factory=...) for mutable defaults

from dataclasses import dataclass, field

@dataclass
class User:
    name: str
    age: int
    tags: list = field(default_factory=list)

u = User("Alice", 30)
print(u)  # User(name='Alice', age=30, tags=[])
print(u == User("Alice", 30))  # True

User(name='Alice', age=30, tags=[])
True

Mutable defaults without field() are shared across instances

Question 8 / 20

How does `__post_init__` work in dataclasses?

__post_init__ is called automatically after the auto-generated __init__ completes. It provides a hook for:

Validation: Check that field values meet business rules
Computed fields: Derive values from other fields
Transformation: Normalize or convert input data

Fields marked with field(init=False) are not included in __init__ and must be set in __post_init__. Fields using InitVar are passed to __post_init__ as parameters but are not stored as instance attributes.

The execution order is: __init__ sets all fields -> __post_init__ runs with access to all fields.

Pseudo Code

1. @dataclass generates __init__ from field annotations
2. __init__ assigns all fields
3. __init__ calls self.__post_init__() at the end
4. Use field(init=False) for fields not in __init__
5. Use InitVar[type] for init-only parameters passed to __post_init__

Code

from dataclasses import dataclass, field, InitVar
from typing import List
import math

# Validation in __post_init__
@dataclass
class Rectangle:
    width: float
    height: float
    area: float = field(init=False)  # computed, not in __init__

    def __post_init__(self):
        if self.width <= 0 or self.height <= 0:
            raise ValueError("Dimensions must be positive")
        self.area = self.width * self.height

r = Rectangle(10, 5)
print(r)       # Rectangle(width=10, height=5, area=50)
print(r.area)  # 50

try:
    Rectangle(-1, 5)
except ValueError as e:
    print(e)  # Dimensions must be positive

# InitVar -- parameter for __post_init__ only, not stored
@dataclass
class User:
    name: str
    raw_password: InitVar[str]  # passed to __post_init__, not stored
    password_hash: str = field(init=False)

    def __post_init__(self, raw_password: str):
        import hashlib
        self.password_hash = hashlib.sha256(raw_password.encode()).hexdigest()

u = User("Alice", "secret123")
print(u)  # User(name='Alice', password_hash='...')
print(hasattr(u, 'raw_password'))  # False -- not stored

# Transformation in __post_init__
@dataclass
class Config:
    values: List[str]
    separator: InitVar[str] = ","
    normalized: List[str] = field(init=False)

    def __post_init__(self, separator):
        # If values was passed as a string, split it
        if isinstance(self.values, str):
            self.values = self.values.split(separator)
        self.normalized = [v.strip().lower() for v in self.values]

c = Config("  Foo , Bar , BAZ ", separator=",")
print(c.values)      # ['  Foo ', ' Bar ', ' BAZ ']
print(c.normalized)  # ['foo', 'bar', 'baz']

Rectangle(width=10, height=5, area=50)
50
Dimensions must be positive
User(name='Alice', password_hash='fcf730b6d95236ecd3c9fc2d92d7b6b2bb061514961aec041d6c7a7192f592e4')
False
['  Foo ', ' Bar ', ' BAZ ']
['foo', 'bar', 'baz']

Key Points

•__post_init__ runs after __init__ for validation and computed fields
•field(init=False) creates fields set in __post_init__, not __init__
•InitVar[type] creates init-only params passed to __post_init__ but not stored
•Use for validation, normalization, and derived attribute computation

Gotchas

•InitVar fields are NOT instance attributes -- they exist only during __post_init__
•In frozen dataclasses, __post_init__ cannot assign to fields normally -- use object.__setattr__(self, 'field', value)
•__post_init__ is not called if you bypass __init__ (e.g., with copy or pickle)

__post_init__ runs after the auto-generated __init__. Use it for validation, computed fields (field(init=False)), and init-only parameters (InitVar).

•Runs after __init__ for validation and computed fields
•field(init=False) for computed, InitVar for init-only params

from dataclasses import dataclass, field, InitVar

@dataclass
class Circle:
    radius: float
    diameter: float = field(init=False)

    def __post_init__(self):
        if self.radius < 0:
            raise ValueError("Radius must be non-negative")
        self.diameter = self.radius * 2

c = Circle(5)
print(c.diameter)  # 10

InitVar fields are not stored as instance attributes

Question 9 / 20

How do you use `@classmethod` as an alternative constructor?

Python doesn't support constructor overloading (multiple __init__ with different signatures). Instead, @classmethod is used to create alternative constructors (factory methods) that construct instances from different input formats.

The key advantage is using cls() instead of ClassName(), which ensures the method works correctly with inheritance -- subclasses get instances of their own type.

Common examples in the standard library:

dict.fromkeys(['a', 'b'], 0) creates a dict from keys
datetime.fromtimestamp(ts) creates a datetime from Unix timestamp
int.from_bytes(b'\x00\x01', 'big') creates int from bytes

Pseudo Code

1. Define @classmethod that takes cls plus alternative parameters
2. Parse/transform the input into __init__ parameters
3. Return cls(param1, param2) to create the instance
4. Using cls() ensures correct class in inheritance hierarchies

Code

from datetime import datetime

class Date:
    def __init__(self, year: int, month: int, day: int):
        self.year = year
        self.month = month
        self.day = day

    def __repr__(self):
        return f"Date({self.year}, {self.month}, {self.day})"

    @classmethod
    def from_string(cls, date_str: str):
        """Create from 'YYYY-MM-DD' string."""
        year, month, day = map(int, date_str.split("-"))
        return cls(year, month, day)

    @classmethod
    def from_timestamp(cls, ts: float):
        """Create from Unix timestamp."""
        dt = datetime.fromtimestamp(ts)
        return cls(dt.year, dt.month, dt.day)

    @classmethod
    def today(cls):
        """Create for current date."""
        dt = datetime.now()
        return cls(dt.year, dt.month, dt.day)

    @classmethod
    def from_dict(cls, data: dict):
        """Create from dictionary."""
        return cls(data["year"], data["month"], data["day"])

# Multiple ways to create the same object
d1 = Date(2024, 1, 15)
d2 = Date.from_string("2024-01-15")
d3 = Date.from_dict({"year": 2024, "month": 1, "day": 15})
d4 = Date.today()

print(d1)  # Date(2024, 1, 15)
print(d2)  # Date(2024, 1, 15)

# Inheritance works correctly with cls()
class ISODate(Date):
    """Date subclass with ISO formatting."""
    def __repr__(self):
        return f"{self.year:04d}-{self.month:02d}-{self.day:02d}"

iso = ISODate.from_string("2024-01-15")
print(type(iso))  # <class 'ISODate'> -- correct subclass!
print(iso)        # 2024-01-15

# Real-world example: config loading
class Config:
    def __init__(self, **settings):
        self.settings = settings

    @classmethod
    def from_json(cls, path: str):
        import json
        with open(path) as f:
            return cls(**json.load(f))

    @classmethod
    def from_env(cls):
        import os
        return cls(
            debug=os.getenv("DEBUG", "false").lower() == "true",
            host=os.getenv("HOST", "localhost"),
            port=int(os.getenv("PORT", "8080")),
        )

Date(2024, 1, 15)
Date(2024, 1, 15)
<class '__main__.ISODate'>
2024-01-15

Key Points

•@classmethod constructors parse different input formats into __init__ params
•Always use cls() instead of ClassName() to support inheritance
•Python's equivalent of constructor overloading
•Standard library uses this pattern: dict.fromkeys, datetime.fromtimestamp

Gotchas

•Using ClassName() instead of cls() breaks inheritance -- subclasses get parent instances
•Alternative constructors should validate input and raise clear errors
•Too many constructors may indicate the class is doing too much

@classmethod creates alternative constructors that parse different input formats. Use cls() instead of the class name to support inheritance correctly.

•Use cls() not ClassName() for inheritance support
•Python's way to do constructor overloading

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

    @classmethod
    def from_dict(cls, data):
        return cls(data["name"], data["email"])

    @classmethod
    def from_string(cls, s):
        name, email = s.split(",")
        return cls(name.strip(), email.strip())

u = User.from_string("Alice, alice@example.com")
print(u.name)  # Alice

Alice

ClassName() in classmethod breaks inheritance

Question 10 / 20

What is the difference between `new` and `init` in Python?

__new__ and __init__ are both involved in object creation but serve different roles:

__new__(cls, ...): The true constructor. It is a static method (special-cased) that creates and returns a new instance. It is called before __init__. You rarely override it for regular classes.

__init__(self, ...): The initializer. It receives the already-created instance and sets up its attributes. It must return None.

The creation process:

MyClass(args) calls MyClass.__new__(MyClass, args)
If __new__ returns an instance of MyClass, __init__ is called on it
If __new__ returns something else, __init__ is NOT called

You override __new__ when:

Subclassing immutable types (str, int, tuple) that need modification before creation
Implementing the singleton pattern
Controlling instance creation in metaclasses
Creating instances of a different class

Pseudo Code

1. obj = MyClass(args)
2. Python calls: obj = MyClass.__new__(MyClass, args)
3. If isinstance(obj, MyClass): MyClass.__init__(obj, args)
4. __new__ creates the instance, __init__ initializes it
5. Override __new__ for immutable types or singleton pattern

Code

# Normal class -- __new__ is inherited from object
class Normal:
    def __init__(self, value):
        print(f"__init__ called with {value}")
        self.value = value

n = Normal(42)
# __init__ called with 42

# Overriding __new__ -- creating immutable subclass
class UpperStr(str):
    """A string that is always uppercase."""
    def __new__(cls, value):
        # Must override __new__ because str is immutable
        # The value must be set BEFORE the object is created
        instance = super().__new__(cls, value.upper())
        return instance

s = UpperStr("hello")
print(s)         # HELLO
print(type(s))   # <class 'UpperStr'>
print(isinstance(s, str))  # True

# Demonstrating the creation order
class Traced:
    def __new__(cls, value):
        print(f"1. __new__ called with cls={cls.__name__}, value={value}")
        instance = super().__new__(cls)
        print(f"2. Instance created: {type(instance)}")
        return instance

    def __init__(self, value):
        print(f"3. __init__ called with self={type(self).__name__}, value={value}")
        self.value = value

t = Traced(42)
# 1. __new__ called with cls=Traced, value=42
# 2. Instance created: <class 'Traced'>
# 3. __init__ called with self=Traced, value=42

# Singleton using __new__
class Singleton:
    _instance = None

    def __new__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

    def __init__(self, value):
        self.value = value  # called every time!

a = Singleton(1)
b = Singleton(2)
print(a is b)    # True
print(a.value)   # 2 -- __init__ ran twice, overwriting

# __new__ returning a different type skips __init__
class Weird:
    def __new__(cls):
        return 42  # not an instance of Weird

    def __init__(self):
        print("This never runs!")

w = Weird()
print(w)       # 42
print(type(w)) # <class 'int'>

__init__ called with 42
HELLO
<class '__main__.UpperStr'>
True
1. __new__ called with cls=Traced, value=42
2. Instance created: <class '__main__.Traced'>
3. __init__ called with self=Traced, value=42
True
2
42
<class 'int'>

Key Points

•__new__ creates the instance (true constructor), __init__ initializes it
•__new__ is called first, receives cls; __init__ receives the created instance
•Override __new__ for immutable types (str, int, tuple) or singletons
•If __new__ returns non-instance of the class, __init__ is not called

Gotchas

•Singleton via __new__ still calls __init__ every time -- it may overwrite attributes
•__new__ must call super().__new__(cls) and return the instance
•Forgetting to return the instance from __new__ returns None
•__init__ must return None -- returning a value raises TypeError

__new__ creates the instance (called first, receives cls). __init__ initializes it (called second, receives self). Override __new__ for immutable types or singletons.

•__new__ creates, __init__ initializes
•Override __new__ for immutable types

class UpperStr(str):
    def __new__(cls, value):
        return super().__new__(cls, value.upper())

s = UpperStr("hello")
print(s)  # HELLO
print(isinstance(s, str))  # True

HELLO
True

__init__ still runs on singleton instances, potentially overwriting state

Question 11 / 20

How does object identity work in Python (`is` vs `==`)?

Python distinguishes between identity and equality:

is checks identity: whether two references point to the exact same object in memory (id(a) == id(b))
== checks equality: whether two objects have the same value (calls __eq__)

Identity implies equality, but equality does not imply identity. Two different objects can have equal values.

CPython caches small integers (-5 to 256) and interned strings, so is may return True unexpectedly for these. This is an implementation detail you should never rely on.

Use is only for:

Comparing to None (if x is None)
Comparing to sentinel objects
Checking if two variables reference the exact same object

Use == for value comparison in all other cases.

Pseudo Code

1. a is b -> True if id(a) == id(b) (same object in memory)
2. a == b -> True if a.__eq__(b) returns True (same value)
3. Use 'is' for None checks and sentinel objects
4. Use '==' for value comparison
5. CPython caches small ints and short strings (implementation detail)

Code

# Identity vs Equality
a = [1, 2, 3]
b = [1, 2, 3]
c = a

print(a == b)  # True -- same value
print(a is b)  # False -- different objects
print(a is c)  # True -- same object
print(id(a), id(b), id(c))  # a and c share id, b is different

# None should always be checked with 'is'
x = None
print(x is None)   # True -- correct
print(x == None)    # True -- works but not Pythonic

# Integer caching (CPython implementation detail)
a = 256
b = 256
print(a is b)  # True -- cached

a = 257
b = 257
print(a is b)  # False (usually) -- not cached
# WARNING: This may be True in some contexts due to compiler optimizations

# String interning
s1 = "hello"
s2 = "hello"
print(s1 is s2)  # True -- interned

s3 = "hello world!"
s4 = "hello world!"
print(s3 is s4)  # May be False -- not always interned

# Mutable objects are never cached
a = (1, 2)
b = (1, 2)
print(a is b)  # May be True (tuple) or False -- depends on context

a = [1, 2]
b = [1, 2]
print(a is b)  # Always False -- lists are mutable, never cached

# Sentinel pattern
_MISSING = object()  # unique sentinel

def get(dictionary, key, default=_MISSING):
    value = dictionary.get(key, _MISSING)
    if value is _MISSING:
        raise KeyError(key)
    return value

True
False
True
4333701440 4333703232 4333701440
True
True
True
True
True
True
True
False

Key Points

•'is' checks identity (same object), '==' checks equality (same value)
•Always use 'is' for None comparison, not '=='
•CPython caches small ints (-5 to 256) and some strings -- implementation detail
•Use sentinel objects with 'is' when None is a valid value

Gotchas

•Never use 'is' for integer or string comparison -- caching makes it unreliable
•a == b may behave unexpectedly if __eq__ is not defined or is buggy
•Integer caching range (-5 to 256) is a CPython detail, not guaranteed by the language

is checks if two references point to the same object (identity). == checks if values are equal. Use is only for None and sentinels. Use == for everything else.

•'is' = same object (identity), '==' = same value (equality)
•Use 'is' for None, sentinels; '==' for everything else

a = [1, 2, 3]
b = [1, 2, 3]
c = a

print(a == b)  # True (same value)
print(a is b)  # False (different objects)
print(a is c)  # True (same object)

x = None
print(x is None)  # True -- always use 'is' for None

True
False
True
True

Small integer caching makes 'is' unreliable for numbers

Question 12 / 20

How do `getattr`, `setattr`, `hasattr`, and `delattr` work?

Python provides four built-in functions for dynamic attribute access:

getattr(obj, name, default): Gets an attribute by string name. Returns default if provided and attribute doesn't exist; raises AttributeError otherwise.
setattr(obj, name, value): Sets an attribute by string name. Equivalent to obj.name = value.
hasattr(obj, name): Returns True if the attribute exists. Internally calls getattr and checks for AttributeError.
delattr(obj, name): Deletes an attribute by string name. Equivalent to del obj.name.

These functions enable metaprogramming: accessing attributes when the attribute name is determined at runtime (e.g., from config files, database columns, or user input).

Pseudo Code

getattr(obj, 'name')        -> obj.name
getattr(obj, 'name', None)  -> obj.name or None if missing
setattr(obj, 'name', value) -> obj.name = value
hasattr(obj, 'name')        -> True if obj.name exists
delattr(obj, 'name')        -> del obj.name

Code

class Config:
    def __init__(self):
        self.host = "localhost"
        self.port = 8080
        self.debug = False

config = Config()

# getattr -- access by string name
print(getattr(config, "host"))           # "localhost"
print(getattr(config, "missing", None))  # None (default)

try:
    getattr(config, "missing")  # AttributeError
except AttributeError:
    print("Attribute not found")

# setattr -- set by string name
setattr(config, "debug", True)
setattr(config, "timeout", 30)  # creates new attribute
print(config.debug)    # True
print(config.timeout)  # 30

# hasattr -- check existence
print(hasattr(config, "host"))     # True
print(hasattr(config, "missing"))  # False

# delattr -- delete by string name
delattr(config, "timeout")
print(hasattr(config, "timeout"))  # False

# Practical: load config from dict
def load_config(obj, settings: dict):
    for key, value in settings.items():
        setattr(obj, key, value)

load_config(config, {"host": "0.0.0.0", "port": 9090})
print(config.host)  # 0.0.0.0
print(config.port)  # 9090

# Practical: serialize object to dict
def to_dict(obj, fields):
    return {f: getattr(obj, f) for f in fields if hasattr(obj, f)}

print(to_dict(config, ["host", "port", "debug", "missing"]))
# {'host': '0.0.0.0', 'port': 9090, 'debug': True}

# Dynamic dispatch pattern
class Handler:
    def handle_login(self, data):
        return f"Login: {data}"

    def handle_logout(self, data):
        return f"Logout: {data}"

    def dispatch(self, action, data):
        method_name = f"handle_{action}"
        method = getattr(self, method_name, None)
        if method is None:
            raise ValueError(f"Unknown action: {action}")
        return method(data)

h = Handler()
print(h.dispatch("login", "user1"))   # Login: user1
print(h.dispatch("logout", "user1"))  # Logout: user1

localhost
None
Attribute not found
True
30
True
False
False
0.0.0.0
9090
{'host': '0.0.0.0', 'port': 9090, 'debug': True}
Login: user1
Logout: user1

Key Points

•getattr/setattr/hasattr/delattr provide dynamic attribute access by string name
•getattr with a default prevents AttributeError
•hasattr internally calls getattr and catches AttributeError
•Enables metaprogramming: dynamic dispatch, serialization, config loading

Gotchas

•hasattr catches ALL exceptions from __getattr__/__getattribute__ in Python 3, not just AttributeError
•setattr can create new attributes unless __slots__ restricts it
•Using these functions with unsanitized user input is a security risk

getattr(obj, 'name') gets attributes by string. setattr sets them. hasattr checks existence. delattr removes them. Used for dynamic/runtime attribute access.

•Dynamic attribute access by string name
•getattr with default prevents AttributeError

class Obj:
    x = 10

o = Obj()
print(getattr(o, 'x'))           # 10
print(getattr(o, 'y', 'default'))  # 'default'
setattr(o, 'y', 20)
print(hasattr(o, 'y'))           # True
delattr(o, 'y')
print(hasattr(o, 'y'))           # False

10
default
True
False

hasattr swallows all exceptions from property getters, not just AttributeError

Question 13 / 20

What is `dict` and how does Python's attribute namespace work?

Every Python object (unless using __slots__) has a __dict__ attribute -- a dictionary that stores the object's writable attributes. This is the namespace where instance attributes live.

Classes also have __dict__ (actually a mappingproxy -- a read-only view), containing class attributes, methods, and other class-level definitions.

Attribute lookup order (simplified):

Data descriptors from the class (e.g., properties with __set__)
Instance __dict__
Non-data descriptors and other class attributes (via MRO)

You can directly manipulate __dict__ to add, modify, or inspect attributes, though this bypasses descriptors and properties.

Pseudo Code

1. instance.__dict__ stores instance attributes
2. Class.__dict__ stores class attributes and methods (mappingproxy)
3. Attribute lookup: data descriptors -> instance.__dict__ -> class.__dict__ -> bases
4. obj.x = v is equivalent to obj.__dict__['x'] = v (without descriptors)
5. vars(obj) returns obj.__dict__

Code

class Person:
    species = "human"  # class attribute

    def __init__(self, name, age):
        self.name = name  # instance attribute
        self.age = age

    def greet(self):
        return f"Hi, I'm {self.name}"

p = Person("Alice", 30)

# Instance __dict__ -- only instance attributes
print(p.__dict__)  # {'name': 'Alice', 'age': 30}

# Class __dict__ -- class attributes, methods, etc.
print(dict(Person.__dict__))
# {'species': 'human', '__init__': <function>, 'greet': <function>, ...}

# vars() is equivalent to __dict__
print(vars(p))  # {'name': 'Alice', 'age': 30}

# Direct manipulation
p.__dict__['email'] = 'alice@example.com'
print(p.email)  # alice@example.com

# Bulk update attributes
p.__dict__.update({'name': 'Bob', 'age': 25})
print(p.name)  # Bob

# Attribute lookup demonstration
print('name' in p.__dict__)     # True -- instance attribute
print('species' in p.__dict__)  # False -- class attribute
print(p.species)  # 'human' -- found in class __dict__

# Shadowing class attribute
p.species = "cyborg"  # creates instance attribute
print(p.__dict__)    # {'name': 'Bob', 'age': 25, 'email': '...', 'species': 'cyborg'}
print(Person.species)  # 'human' -- class attribute unchanged

del p.species  # remove instance shadow
print(p.species)  # 'human' -- falls back to class attribute

# Class __dict__ is a mappingproxy (read-only view)
print(type(Person.__dict__))  # <class 'mappingproxy'>
try:
    Person.__dict__['x'] = 1  # TypeError: read-only
except TypeError:
    Person.x = 1  # This works -- goes through __setattr__

{'name': 'Alice', 'age': 30}
{'__module__': '__main__', 'species': 'human', '__init__': <function Person.__init__ at <address>>, 'greet': <function Person.greet at <address>>, '__dict__': <attribute '__dict__' of 'Person' objects>, '__weakref__': <attribute '__weakref__' of 'Person' objects>, '__doc__': None}
{'name': 'Alice', 'age': 30}
alice@example.com
Bob
True
False
human
{'name': 'Bob', 'age': 25, 'email': 'alice@example.com', 'species': 'cyborg'}
human
human
<class 'mappingproxy'>

Key Points

•instance.__dict__ stores instance attributes as a regular dict
•Class.__dict__ is a mappingproxy (read-only view) of class attributes
•vars(obj) returns obj.__dict__
•Attribute lookup checks instance __dict__ then class __dict__ (with MRO)

Gotchas

•Directly modifying __dict__ bypasses descriptors and properties
•Objects with __slots__ do not have __dict__ (unless __dict__ is in __slots__)
•Class.__dict__ is read-only (mappingproxy) -- use setattr or direct assignment on the class

__dict__ is a dictionary holding an object's attributes. Instance __dict__ has instance attributes; class __dict__ has class attributes and methods. vars(obj) returns __dict__.

•__dict__ stores writable attributes per object
•Instance attrs in instance.__dict__, class attrs in Class.__dict__

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

d = Dog("Rex")
print(d.__dict__)         # {'name': 'Rex'}
print('species' in d.__dict__)  # False (class attr)
print(vars(d))            # {'name': 'Rex'}

{'name': 'Rex'}
False
{'name': 'Rex'}

Modifying __dict__ directly bypasses properties and descriptors

Question 14 / 20

What are Python's naming conventions for private and protected attributes?

Python doesn't have true access modifiers like Java or C++. Instead, it uses naming conventions:

Public (name): No underscore. Part of the public API.
Protected (_name): Single underscore prefix. Convention meaning "internal use" -- not enforced, but respected by developers and linters. Not imported with from module import *.
Private (__name): Double underscore prefix. Triggers name mangling: Python renames it to _ClassName__name to prevent accidental override in subclasses. Still accessible if you know the mangled name.
Dunder (__name__): Double underscore prefix AND suffix. Reserved for Python special methods. Never invent your own dunders.

Name mangling exists not for security, but to prevent accidental name collisions in inheritance hierarchies. Python's philosophy is "we're all consenting adults here" -- the conventions are respected voluntarily.

Pseudo Code

1. public_attr -- public API
2. _protected_attr -- internal use by convention
3. __private_attr -- name-mangled to _ClassName__private_attr
4. __dunder__ -- Python special methods
5. Single underscore: respected by convention
6. Double underscore: name mangling prevents subclass collisions

Code

class Account:
    def __init__(self, owner, balance):
        self.owner = owner          # public
        self._balance = balance     # protected (convention)
        self.__pin = 1234           # private (name-mangled)

    def get_pin(self):
        return self.__pin  # works inside the class

a = Account("Alice", 1000)

# Public -- always accessible
print(a.owner)  # Alice

# Protected -- accessible but convention says "don't touch"
print(a._balance)  # 1000 (works, but frowned upon externally)

# Private -- name mangling
try:
    print(a.__pin)  # AttributeError!
except AttributeError:
    print("Cannot access __pin directly")

# But it IS accessible via mangled name
print(a._Account__pin)  # 1234
print(a.get_pin())       # 1234

# Name mangling prevents subclass collision
class SpecialAccount(Account):
    def __init__(self, owner, balance, special_pin):
        super().__init__(owner, balance)
        self.__pin = special_pin  # becomes _SpecialAccount__pin

sa = SpecialAccount("Bob", 2000, 9999)
print(sa._Account__pin)         # 1234 (parent's __pin)
print(sa._SpecialAccount__pin)  # 9999 (child's __pin)
print(sa.get_pin())             # 1234 (parent method uses parent's __pin)

# What shows in __dict__
print(sa.__dict__)
# {'owner': 'Bob', '_balance': 2000, '_Account__pin': 1234, '_SpecialAccount__pin': 9999}

# Convention summary
class Example:
    def public_method(self):        pass  # part of public API
    def _internal_method(self):     pass  # internal use
    def __private_method(self):     pass  # name-mangled
    def __special_method__(self):   pass  # Python protocol (dunder)

Alice
1000
Cannot access __pin directly
1234
1234
1234
9999
1234
{'owner': 'Bob', '_balance': 2000, '_Account__pin': 1234, '_SpecialAccount__pin': 9999}

Key Points

•Single underscore (_name): protected by convention, not enforced
•Double underscore (__name): name-mangled to _ClassName__name
•Name mangling prevents accidental override in subclasses
•Python has no true access modifiers -- it's all conventions

Gotchas

•Name mangling only applies to names with 2+ leading underscores and at most 1 trailing underscore
•Mangled names are still accessible via _ClassName__name -- it's not security
•Don't use double underscore for general privacy -- use single underscore; double is for subclass collision prevention
•Name mangling happens at compile time based on the class it's defined in

Single underscore _name = protected by convention. Double underscore __name = name-mangled to _ClassName__name to prevent subclass collisions. Python has no true private attributes.

•_name = convention, __name = name mangling
•No true access control -- 'we're all consenting adults'

class Foo:
    def __init__(self):
        self.public = 1
        self._protected = 2    # convention: internal
        self.__private = 3     # mangled to _Foo__private

f = Foo()
print(f.public)          # 1
print(f._protected)      # 2 (accessible but discouraged)
print(f._Foo__private)   # 3 (mangled name)

1
2
3

Use __ only to prevent subclass collisions, not for general privacy

Question 15 / 20

What is the difference between `repr` and `str`?

__repr__ and __str__ both return string representations of an object, but serve different purposes:

__repr__: The "official" string representation. Should be unambiguous and ideally valid Python code that could recreate the object. Used by repr(), the interactive console, and debuggers. If __str__ is not defined, __repr__ is used as a fallback.

__str__: The "informal" or "pretty" string representation. Should be readable and user-friendly. Used by str(), print(), and f-strings.

Rule of thumb from the Python docs:

__repr__ is for developers (debugging)
__str__ is for end users (display)

If you implement only one, implement __repr__. It serves as the fallback for __str__ and is the most useful for debugging.

Pseudo Code

1. __repr__ -> unambiguous, developer-facing, ideally recreatable
2. __str__ -> readable, user-facing, pretty
3. repr(obj) calls __repr__
4. str(obj), print(obj), f'{obj}' call __str__
5. If __str__ is missing, falls back to __repr__
6. Always implement __repr__; __str__ is optional

Code

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

    def __repr__(self):
        return f"Point({self.x!r}, {self.y!r})"  # unambiguous, recreatable

    def __str__(self):
        return f"({self.x}, {self.y})"  # readable, user-friendly

p = Point(3, 4)

# __repr__ -- for developers
print(repr(p))    # Point(3, 4)
print([p])        # [Point(3, 4)] -- containers use __repr__

# __str__ -- for users
print(str(p))     # (3, 4)
print(p)          # (3, 4) -- print uses __str__
print(f"Point: {p}")  # Point: (3, 4) -- f-strings use __str__

# Container behavior: containers always use __repr__ for their elements
points = [Point(1, 2), Point(3, 4)]
print(points)     # [Point(1, 2), Point(3, 4)] -- uses __repr__!

# Fallback: without __str__, __repr__ is used
class OnlyRepr:
    def __repr__(self):
        return "OnlyRepr()"

obj = OnlyRepr()
print(repr(obj))  # OnlyRepr()
print(str(obj))   # OnlyRepr() -- falls back to __repr__
print(obj)        # OnlyRepr()

# Real-world example
from datetime import datetime

dt = datetime(2024, 1, 15, 10, 30)
print(repr(dt))  # datetime.datetime(2024, 1, 15, 10, 30)
print(str(dt))   # 2024-01-15 10:30:00

# Best practice: use !r in __repr__ for string fields
class User:
    def __init__(self, name, role):
        self.name = name
        self.role = role

    def __repr__(self):
        return f"User({self.name!r}, {self.role!r})"  # adds quotes

u = User("Alice", "admin")
print(repr(u))  # User('Alice', 'admin') -- quotes make it recreatable

Point(3, 4)
[Point(3, 4)]
(3, 4)
(3, 4)
Point: (3, 4)
[Point(1, 2), Point(3, 4)]
OnlyRepr()
OnlyRepr()
OnlyRepr()
datetime.datetime(2024, 1, 15, 10, 30)
2024-01-15 10:30:00
User('Alice', 'admin')

Key Points

•__repr__ for developers (unambiguous), __str__ for users (readable)
•Containers (lists, dicts) always use __repr__ for their elements
•If __str__ is missing, Python falls back to __repr__
•Use !r format spec in __repr__ to add quotes around string values

Gotchas

•Lists/dicts use __repr__ for elements, not __str__ -- print([obj]) uses __repr__
•If you only implement __str__ without __repr__, debugging output is unhelpful
•f-strings use __str__ by default; use !r to force __repr__

__repr__ is for developers (unambiguous, like valid Python). __str__ is for users (readable). print() uses __str__, containers use __repr__. Always implement __repr__ first.

•__repr__ = developer-facing, __str__ = user-facing
•__repr__ is fallback when __str__ is missing

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

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

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

p = Point(3, 4)
print(repr(p))  # Point(3, 4)
print(str(p))   # (3, 4)
print([p])      # [Point(3, 4)]  -- container uses __repr__

Point(3, 4)
(3, 4)
[Point(3, 4)]

Containers always use __repr__ for their elements

Question 16 / 20

How do you use `getattr` and `getattribute` for custom attribute access?

Python provides two hooks for customizing attribute access:

__getattribute__(self, name): Called for EVERY attribute access on the instance, before checking __dict__. Very powerful but dangerous -- easy to create infinite recursion. Defined on object by default.

__getattr__(self, name): Called ONLY when normal attribute lookup fails (not found in __dict__, class, or base classes). It's the fallback handler. Much safer to override.

Lookup order:

__getattribute__ is called
It checks data descriptors, instance.__dict__, class/bases
If nothing is found, __getattr__ is called
If __getattr__ also fails, AttributeError is raised

Use __getattr__ for: proxy objects, dynamic attributes, deprecation warnings, lazy loading. Use __getattribute__ for: logging all access, access control, read-only objects.

Pseudo Code

1. obj.x triggers __getattribute__('x')
2. __getattribute__ checks: data descriptors -> __dict__ -> class attrs
3. If not found: __getattr__('x') is called as fallback
4. Override __getattr__ for missing attribute handling
5. Override __getattribute__ for ALL attribute access (careful!)

Code

# __getattr__ -- called only when attribute is NOT found
class DynamicConfig:
    def __init__(self, **kwargs):
        self.__dict__.update(kwargs)

    def __getattr__(self, name):
        """Called when attribute is not found normally."""
        # Return a default value for any missing attribute
        return f"<undefined: {name}>"

config = DynamicConfig(host="localhost", port=8080)
print(config.host)     # localhost (found in __dict__)
print(config.missing)  # <undefined: missing> (__getattr__ called)

# Proxy pattern with __getattr__
class LoggingProxy:
    """Wraps an object and logs all attribute access."""
    def __init__(self, target):
        self._target = target

    def __getattr__(self, name):
        print(f"Accessing: {name}")
        return getattr(self._target, name)

proxy = LoggingProxy([1, 2, 3])
proxy.append(4)  # Accessing: append
print(proxy._target)  # [1, 2, 3, 4] (found in __dict__, no log)

# __getattribute__ -- called for EVERY access (dangerous!)
class ReadOnly:
    def __init__(self, **kwargs):
        for k, v in kwargs.items():
            object.__setattr__(self, k, v)  # bypass our override

    def __setattr__(self, name, value):
        raise AttributeError("Read-only object")

    def __getattribute__(self, name):
        print(f"[READ] {name}")
        return object.__getattribute__(self, name)  # MUST use object's version!

r = ReadOnly(x=10, y=20)
print(r.x)  # [READ] x \n 10

# DANGER: infinite recursion without object.__getattribute__
class Broken:
    def __getattribute__(self, name):
        # self.data causes infinite recursion!
        # return self.data[name]  # DON'T DO THIS
        return object.__getattribute__(self, name)  # correct

# Practical: deprecation proxy
class DeprecatedAttrs:
    _deprecated = {'old_name': 'new_name', 'legacy': 'modern'}

    def __init__(self):
        self.new_name = "value"
        self.modern = "updated"

    def __getattr__(self, name):
        if name in self._deprecated:
            import warnings
            new = self._deprecated[name]
            warnings.warn(f"{name} is deprecated, use {new}",
                          DeprecationWarning, stacklevel=2)
            return getattr(self, new)
        raise AttributeError(f"No attribute {name}")

obj = DeprecatedAttrs()
print(obj.new_name)   # "value" (normal access)
print(obj.old_name)   # DeprecationWarning + "value"

localhost
<undefined: missing>
Accessing: append
[1, 2, 3, 4]
[READ] x
10
value
value

Key Points

•__getattr__ is called only when normal lookup fails -- safe fallback handler
•__getattribute__ is called for EVERY access -- powerful but risky
•Always use object.__getattribute__ inside __getattribute__ to avoid infinite recursion
•Common uses: proxies, dynamic attributes, deprecation, lazy loading

Gotchas

•Accessing self.anything inside __getattribute__ causes infinite recursion -- use object.__getattribute__
•__getattr__ is NOT called if the attribute exists in __dict__ or class
•hasattr catches exceptions from __getattr__, so it returns True if __getattr__ doesn't raise

__getattr__ is called when attribute lookup fails (safe fallback). __getattribute__ is called for every access (dangerous, causes recursion). Use __getattr__ for proxies and defaults.

•__getattr__ = fallback for missing attributes (safe)
•__getattribute__ = all access (dangerous, needs object.__getattribute__)

class Default:
    def __init__(self):
        self.x = 10

    def __getattr__(self, name):
        return f"<{name} not found>"

d = Default()
print(d.x)       # 10 (normal lookup)
print(d.missing) # <missing not found> (__getattr__ fallback)

10
<missing not found>

Never access self.x inside __getattribute__ -- use object.__getattribute__(self, 'x')

Question 17 / 20

How do you create a class that supports comparison and hashing?

For a class to work correctly in sets and as dict keys, it must implement both __eq__ and __hash__ consistently.

Rules:

Objects that compare equal must have the same hash: a == b implies hash(a) == hash(b)
If you define __eq__, Python sets __hash__ to None (making instances unhashable)
You must explicitly define __hash__ alongside __eq__ if you want hashability
Hash should be based on the same fields used in __eq__
Only immutable fields should contribute to the hash (mutable fields that change would break sets/dicts)

The @functools.total_ordering decorator can generate all comparison methods from just __eq__ and one of __lt__, __le__, __gt__, __ge__.

Pseudo Code

1. Define __eq__(self, other) for equality comparison
2. Define __hash__(self) using same fields as __eq__
3. Hash must be based on immutable data
4. a == b implies hash(a) == hash(b) (MUST hold)
5. Use @total_ordering + __eq__ + __lt__ for full comparison support

Code

from functools import total_ordering

@total_ordering
class Money:
    def __init__(self, amount, currency="USD"):
        self.amount = amount
        self.currency = currency

    def __eq__(self, other):
        if not isinstance(other, Money):
            return NotImplemented
        return self.amount == other.amount and self.currency == other.currency

    def __hash__(self):
        # Based on same fields as __eq__
        return hash((self.amount, self.currency))

    def __lt__(self, other):
        if not isinstance(other, Money):
            return NotImplemented
        if self.currency != other.currency:
            raise ValueError(f"Cannot compare {self.currency} with {other.currency}")
        return self.amount < other.amount

    def __repr__(self):
        return f"Money({self.amount}, {self.currency!r})"

# Equality and hashing
m1 = Money(100, "USD")
m2 = Money(100, "USD")
m3 = Money(200, "USD")

print(m1 == m2)      # True
print(m1 == m3)      # False
print(hash(m1) == hash(m2))  # True (equal objects, same hash)

# Works in sets and dicts
prices = {m1, m2, m3}  # m1 and m2 are deduplicated
print(len(prices))  # 2

price_map = {m1: "cheap", m3: "expensive"}
print(price_map[Money(100, "USD")])  # "cheap" -- lookup works

# @total_ordering generates <=, >, >= from __eq__ and __lt__
print(m1 < m3)   # True
print(m1 <= m2)  # True (generated by @total_ordering)
print(m3 > m1)   # True (generated)
print(m3 >= m3)  # True (generated)

# Without __eq__, Python uses identity (is) by default
class Default:
    pass

a = Default()
b = Default()
print(a == b)  # False (different objects)
print(hash(a) != hash(b))  # True (based on id)

# NotImplemented allows Python to try the other operand
print(m1 == "not money")  # False (Python handles NotImplemented)
try:
    print(m1 < 100)
except TypeError as e:
    print(f"TypeError: {e}")  # both sides return NotImplemented

True
False
True
2
cheap
True
True
True
True
False
True
False
TypeError: '<' not supported between instances of 'Money' and 'int'

Key Points

•Define __eq__ and __hash__ together using the same fields
•Equal objects MUST have equal hashes
•Return NotImplemented for unsupported operand types
•@total_ordering generates all comparison methods from __eq__ + one ordering method

Gotchas

•Defining __eq__ without __hash__ makes instances unhashable (can't use in sets/dicts)
•Mutable objects with changing hash values break sets and dicts
•Return NotImplemented (not NotImplementedError) for type mismatches in comparisons
•@total_ordering has slight performance overhead -- implement all methods for hot paths

Implement __eq__ and __hash__ using the same fields. Use @total_ordering with __eq__ + __lt__ to get all comparison operators. Return NotImplemented for type mismatches.

•__eq__ + __hash__ on same fields for set/dict support
•@total_ordering fills in missing comparison methods

from functools import total_ordering

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

    def __eq__(self, other):
        if not isinstance(other, Point):
            return NotImplemented
        return (self.x, self.y) == (other.x, other.y)

    def __hash__(self):
        return hash((self.x, self.y))

    def __lt__(self, other):
        if not isinstance(other, Point):
            return NotImplemented
        return (self.x, self.y) < (other.x, other.y)

points = {Point(1, 2), Point(1, 2), Point(3, 4)}
print(len(points))  # 2

No __hash__ after defining __eq__ = unhashable

Question 18 / 20

How do you use `__init_subclass__` to customize subclass creation?

__init_subclass__ (Python 3.6+) is a hook called on the parent class whenever a new subclass is defined. It provides a simpler alternative to metaclasses for customizing subclass behavior.

When class Child(Parent): is defined, Python calls Parent.__init_subclass__ with cls set to Child. You can use keyword arguments in the class definition to pass configuration to the hook.

Common uses:

Registering subclasses automatically (plugin systems)
Enforcing constraints on subclass definitions
Injecting attributes or methods into subclasses

Pseudo Code

1. Define __init_subclass__(cls, **kwargs) in parent class
2. Called automatically when any subclass is defined
3. cls is the new subclass being created
4. Keyword args from class definition are passed through
5. Call super().__init_subclass__(**kwargs) for cooperative inheritance

Code

# Automatic subclass registration (plugin pattern)
class Plugin:
    _registry = {}

    def __init_subclass__(cls, plugin_name=None, **kwargs):
        super().__init_subclass__(**kwargs)
        name = plugin_name or cls.__name__.lower()
        cls._registry[name] = cls
        cls.plugin_name = name

    @classmethod
    def get_plugin(cls, name):
        return cls._registry.get(name)

class JSONPlugin(Plugin, plugin_name="json"):
    def process(self, data):
        return f"Processing JSON: {data}"

class XMLPlugin(Plugin, plugin_name="xml"):
    def process(self, data):
        return f"Processing XML: {data}"

class CSVPlugin(Plugin):  # auto-named "csvplugin"
    def process(self, data):
        return f"Processing CSV: {data}"

print(Plugin._registry)
# {'json': <class 'JSONPlugin'>, 'xml': <class 'XMLPlugin'>, 'csvplugin': <class 'CSVPlugin'>}

plugin_cls = Plugin.get_plugin("json")
plugin = plugin_cls()
print(plugin.process('{"key": "value"}'))
# Processing JSON: {"key": "value"}

# Enforcing constraints on subclasses
class Serializable:
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        if not hasattr(cls, 'serialize'):
            raise TypeError(f"{cls.__name__} must implement serialize()")
        if not hasattr(cls, 'deserialize'):
            raise TypeError(f"{cls.__name__} must implement deserialize()")

class UserData(Serializable):
    def serialize(self):
        return str(self.__dict__)

    @classmethod
    def deserialize(cls, data):
        return cls()

# This would raise TypeError at class definition time:
# class Broken(Serializable):
#     pass  # TypeError: Broken must implement serialize()

{'json': <class '__main__.JSONPlugin'>, 'xml': <class '__main__.XMLPlugin'>, 'csvplugin': <class '__main__.CSVPlugin'>}
Processing JSON: {"key": "value"}

Key Points

•__init_subclass__ is called when a subclass is defined, not instantiated
•Simpler alternative to metaclasses for many use cases
•Keyword args in class definition are passed to __init_subclass__
•Always call super().__init_subclass__(**kwargs) for cooperative inheritance

Gotchas

•It's called at class definition time, not at instantiation time
•Forgetting super().__init_subclass__(**kwargs) breaks cooperative inheritance
•The parent class itself does not trigger __init_subclass__ -- only subclasses do
•Cannot intercept all metaclass features -- use metaclasses for more advanced control

__init_subclass__ is called on the parent when a subclass is defined. Use it for plugin registration, subclass validation, or injecting behavior. Simpler than metaclasses.

•Called at class definition time for each subclass
•Simpler alternative to metaclasses

class Animal:
    _types = []

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Animal._types.append(cls.__name__)

class Dog(Animal): pass
class Cat(Animal): pass

print(Animal._types)  # ['Dog', 'Cat']

['Dog', 'Cat']

Always call super().__init_subclass__(**kwargs)

Question 19 / 20

How does method resolution order (MRO) affect attribute lookup on instances?

When you access an attribute on an instance, Python follows a specific lookup chain that involves the MRO (Method Resolution Order):

Data descriptors from the type (class) and its MRO (e.g., properties with __set__)
Instance __dict__ (instance attributes)
Non-data descriptors and other attributes from the type and its MRO

The MRO is the order in which Python searches base classes. It's computed using the C3 linearization algorithm and can be inspected via ClassName.__mro__ or ClassName.mro().

This lookup chain explains why properties (data descriptors) override instance attributes, and why you can shadow class methods with instance attributes.

Pseudo Code

Attribute lookup for obj.x:
1. type(obj).__mro__ gives the search order
2. Check for data descriptor x in class/bases (has __get__ AND __set__)
3. Check obj.__dict__ for x
4. Check for non-data descriptor or regular attr in class/bases
5. If nothing found, call __getattr__ if defined
6. Raise AttributeError

Code

class Base:
    x = "from Base"

class Middle(Base):
    pass

class Child(Middle):
    pass

# MRO determines search order
print(Child.__mro__)
# (<class 'Child'>, <class 'Middle'>, <class 'Base'>, <class 'object'>)

c = Child()
print(c.x)  # "from Base" -- found via MRO

# Instance attribute shadows class attribute
c.x = "instance value"
print(c.x)  # "instance value" -- instance __dict__ wins
print(Child.x)  # "from Base" -- class still has it

del c.x
print(c.x)  # "from Base" -- falls back to class

# Data descriptor (property) wins over instance __dict__
class WithProperty:
    @property
    def value(self):
        return "from property"

obj = WithProperty()
# obj.__dict__['value'] = 'instance'  # This won't help!
# obj.value would still return 'from property'
# Because property is a data descriptor (has __set__)

# But we can force it via __dict__ directly
obj.__dict__['value'] = 'forced'
# Still, obj.value returns 'from property' because data descriptor wins
print(obj.value)  # 'from property' -- data descriptor wins over __dict__

# Non-data descriptor (function) can be shadowed
class Example:
    def method(self):
        return "method"

e = Example()
print(e.method())  # "method"
e.method = lambda: "shadowed"
print(e.method())  # "shadowed" -- instance attr shadows non-data descriptor

del e.method
print(e.method())  # "method" -- back to class method

# Practical MRO impact
class A:
    def who(self): return "A"
class B(A):
    pass
class C(A):
    def who(self): return "C"
class D(B, C):
    pass

print(D.__mro__)
# D -> B -> C -> A -> object
print(D().who())  # "C" -- B doesn't have who, so C is next in MRO

(<class 'Child'>, <class 'Middle'>, <class 'Base'>, <class 'object'>)
from Base
instance value
from Base
from Base
from property
method
shadowed
method
(<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>)
C

Key Points

•Lookup: data descriptors -> instance __dict__ -> non-data descriptors/class attrs
•MRO (C3 linearization) determines the search order through base classes
•Instance attributes shadow class attributes (for non-data descriptors)
•Data descriptors (properties) take priority over instance __dict__

Gotchas

•Properties (data descriptors) cannot be shadowed by instance attributes
•Functions are non-data descriptors and CAN be shadowed by instance attributes
•MRO with diamond inheritance may not match your intuition -- always check __mro__

Attribute lookup follows MRO: data descriptors (properties) first, then instance __dict__, then class attributes via MRO. Use Class.__mro__ to see the search order.

•Data descriptors > instance __dict__ > class/MRO attrs
•C3 linearization determines MRO

class A:
    x = "A"
class B(A):
    pass
class C(A):
    x = "C"
class D(B, C):
    pass

print(D.__mro__)  # D -> B -> C -> A -> object
print(D().x)      # "C" (B has no x, C is next in MRO)

(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
C

Properties override instance __dict__ (data descriptor priority)

Question 20 / 20

What are the best practices for designing Python classes?

Python class design follows several key principles:

Favor composition over inheritance: Use has-a relationships instead of is-a when possible. It's more flexible and easier to test.
Keep classes focused (SRP): Each class should have one responsibility. If a class does too many things, split it.
Use dataclasses for data containers: If a class mainly holds data, @dataclass eliminates boilerplate.
Prefer properties over getters/setters: Use @property instead of get_x()/set_x() methods.
Implement __repr__ for every class: Essential for debugging.
Use __slots__ for performance-critical classes: When creating millions of instances.
Follow naming conventions: _private for internal, __mangled for subclass collision prevention.
Use type hints: Annotate __init__ parameters and method signatures.
Avoid deep inheritance hierarchies: Prefer shallow hierarchies and mixins.
Design for duck typing: Check behavior, not type. Use protocols (typing.Protocol) for interfaces.

Pseudo Code

1. One responsibility per class
2. Composition > inheritance
3. @dataclass for data-heavy classes
4. @property for controlled attribute access
5. Always implement __repr__
6. Type hints on all methods
7. __slots__ for memory-critical classes
8. Shallow inheritance, use mixins
9. Duck typing over isinstance checks
10. Document public API with docstrings

Code

from dataclasses import dataclass, field
from typing import List, Protocol

# Good: dataclass for data containers
@dataclass
class Address:
    street: str
    city: str
    state: str
    zip_code: str

# Good: composition over inheritance
@dataclass
class Employee:
    name: str
    email: str
    address: Address  # composition (has-a)
    skills: List[str] = field(default_factory=list)

    def __repr__(self):
        return f"Employee({self.name!r}, {self.email!r})"

# Good: Protocol for duck typing (structural subtyping)
class Sendable(Protocol):
    def send(self, message: str) -> bool: ...

class EmailSender:
    def send(self, message: str) -> bool:
        print(f"Email: {message}")
        return True

class SlackSender:
    def send(self, message: str) -> bool:
        print(f"Slack: {message}")
        return True

def notify(sender: Sendable, msg: str) -> bool:
    return sender.send(msg)  # works with any object that has send()

# Good: small, focused classes with clear responsibilities
class PasswordValidator:
    def __init__(self, min_length: int = 8):
        self.min_length = min_length

    def validate(self, password: str) -> List[str]:
        errors = []
        if len(password) < self.min_length:
            errors.append(f"Must be at least {self.min_length} characters")
        if not any(c.isupper() for c in password):
            errors.append("Must contain an uppercase letter")
        if not any(c.isdigit() for c in password):
            errors.append("Must contain a digit")
        return errors

# Good: __slots__ for high-volume instances
class Point:
    __slots__ = ('x', 'y')

    def __init__(self, x: float, y: float):
        self.x = x
        self.y = y

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

# Usage
addr = Address("123 Main St", "Springfield", "IL", "62701")
emp = Employee("Alice", "alice@company.com", addr, ["Python", "SQL"])
print(emp)  # Employee('Alice', 'alice@company.com')

notify(EmailSender(), "Hello!")  # Email: Hello!
notify(SlackSender(), "Hello!")  # Slack: Hello!

validator = PasswordValidator(min_length=10)
errors = validator.validate("short")
print(errors)  # ['Must be at least 10 characters', 'Must contain an uppercase letter', 'Must contain a digit']

Employee('Alice', 'alice@company.com')
Email: Hello!
Slack: Hello!
['Must be at least 10 characters', 'Must contain an uppercase letter', 'Must contain a digit']

Key Points

•Composition over inheritance for flexibility
•dataclasses for data containers, __slots__ for performance
•Protocol for duck typing interfaces
•Always implement __repr__, use type hints, keep classes focused

Gotchas

•Over-engineering with deep inheritance hierarchies makes code harder to understand
•isinstance checks are often a code smell -- prefer duck typing
•Mutable class-level defaults are shared across instances
•Too many properties can make a class harder to reason about than simple attributes

Use @dataclass for data classes, composition over inheritance, @property over getters/setters, always implement __repr__, use type hints, and prefer duck typing with Protocol.

•dataclass for data, composition over inheritance
•Protocol for duck-typed interfaces

from dataclasses import dataclass
from typing import Protocol

@dataclass
class User:
    name: str
    email: str

    def __repr__(self):
        return f"User({self.name!r})"

class Notifier(Protocol):
    def notify(self, msg: str) -> None: ...

def send_alert(notifier: Notifier, msg: str):
    notifier.notify(msg)  # duck typing

Deep inheritance makes code hard to follow

Built by onllm.dev

Home GitHub Support awesomePrep

How do you define a class in Python, and what is the role of `__init__`?

What is the difference between instance variables and class variables in Python?

What is the difference between instance methods, class methods, and static methods?

How does `self` work in Python, and why is it explicitly required?

How does the `@property` decorator work for encapsulation in Python classes?

What is `__slots__` and when should you use it?

How do dataclasses work in Python, and when should you use them?

How does `__post_init__` work in dataclasses?

How do you use `@classmethod` as an alternative constructor?

What is the difference between `__new__` and `__init__` in Python?

How does object identity work in Python (`is` vs `==`)?

How do `getattr`, `setattr`, `hasattr`, and `delattr` work?

What is `__dict__` and how does Python's attribute namespace work?

What are Python's naming conventions for private and protected attributes?

What is the difference between `__repr__` and `__str__`?

How do you use `__getattr__` and `__getattribute__` for custom attribute access?

How do you create a class that supports comparison and hashing?

How do you use `__init_subclass__` to customize subclass creation?

How does method resolution order (MRO) affect attribute lookup on instances?

What are the best practices for designing Python classes?

OOP: Classes & Objects

How do you define a class in Python, and what is the role of `init`?

What is `slots` and when should you use it?

What is the difference between `new` and `init` in Python?

What is `dict` and how does Python's attribute namespace work?

What is the difference between `repr` and `str`?

How do you use `getattr` and `getattribute` for custom attribute access?