Object-oriented programming (OOP) is a way of organising code around objects: bundles of data (attributes) and the functions that operate on that data (methods). Instead of passing a dictionary of account details to a dozen loose functions, you create a BankAccount object that *knows* its balance and *knows how* to deposit, withdraw and print a statement.

In Python, everything you have used so far is already an object. The integer 42, the string "Mumbai", the list [1, 2, 3], even functions and modules are objects with a type and attributes. Lecture 5 showed you list.append() and dict.items(): those are methods on built-in classes. This lecture teaches you to build your own.

Why OOP matters in real projects:

• Modelling the domain — an e-commerce backend has Customer, Order, Payment and Shipment objects. Code that mirrors the business is easier to read and discuss with non-programmers.
• Encapsulation — the rules for changing a balance live inside BankAccount, so nobody can accidentally set it to a negative number from somewhere else in the codebase.
• Reuse through inheritance and composition — Django models, FastAPI dependencies, pandas DataFrames, PyTorch modules and pytest fixtures are all built on classes. You cannot read framework source code, or write a plugin for it, without understanding OOP.
• Testability — small objects with clear responsibilities are easy to unit-test and mock.

Python's OOP is deliberately lightweight compared with Java or C++. There is no private keyword, no interfaces in the strict sense, and no requirement to put one class per file. The language trusts you ("we are all consenting adults") and gives you conventions instead of walls. By the end of this lecture you will be able to design a small class hierarchy, override the operators Python uses behind the scenes, protect data with properties, define contracts with abstract base classes and remove boilerplate with dataclasses.

This lecture targets Python 3.13/3.14 (Python 3.14 is the current stable series as of writing, with 3.15 scheduled for October 2026). Version-specific features are labelled as they appear.

A class is a blueprint; an instance (or object) is a concrete thing built from that blueprint. class Student: defines the blueprint, and Student("Priya", 21) builds one student.

Key pieces of syntax:

• class Name: — class names use CapWords (PascalCase) by PEP 8. The body is indented like a function body.
• __init__(self, ...) — the initialiser. Python calls it automatically right after creating a new, empty object. Its job is to attach the starting attributes. It is often called the "constructor", though strictly the object is created by __new__ and *initialised* by __init__.
• self — the first parameter of every instance method. It refers to the specific object the method is being called on. The name self is a convention, not a keyword, but every Python developer expects it.
• Attribute assignment — self.name = name creates an instance attribute. There is no declaration step; the attribute exists the moment you assign it.

When you write priya.greet(), Python translates it to Student.greet(priya). That is exactly why self must be the first parameter and why forgetting it produces the famous "takes 0 positional arguments but 1 was given" error.

Every instance gets its own __dict__, a dictionary that stores its attributes. vars(priya) shows it. You can even add attributes after construction (priya.city = "Pune"), though in production you should set everything in __init__ so readers know what an object contains.

Type hints on __init__ parameters are strongly recommended. They cost nothing at runtime and let editors and tools such as mypy or pyright catch mistakes before you run the code.

There are two places an attribute can live:

• Instance attributes are stored in the object's own __dict__. They are created with self.x = ... and are different for every object. Name, balance, email: anything that varies per object.
• Class attributes are defined directly in the class body (not inside a method). They are stored once on the class and shared by all instances. Use them for constants, defaults and counters: an interest rate, a species name, a registry of created objects.

When you read obj.attr, Python looks in the instance __dict__ first, then in the class, then in parent classes. This is the attribute lookup chain. When you *write* obj.attr = value, Python always writes to the instance, which creates a new instance attribute that *shadows* the class attribute for that one object. The class attribute itself is untouched.

This lookup rule produces the most famous OOP bug in Python: a mutable class attribute such as a list. If Student.marks = [] is a class attribute and every student does self.marks.append(...), all students share one list because append mutates the shared object in place rather than assigning a new one. The fix is to create mutable containers in __init__, exactly as the previous section did.

Legitimate uses of class attributes:

• Constants: GST_RATE = 0.18.
• A counter of how many objects exist (incremented via type(self).count += 1 or ClassName.count += 1).
• Default configuration a subclass can override: timeout = 30.

Note that self.count += 1 would not update the class counter: it reads the class value, adds one and writes an *instance* attribute. Always modify class attributes through the class.

Python classes support three kinds of methods, distinguished by what they receive as their first argument.

Instance methods receive self. They are the default and the most common. They read or change the state of one specific object.

Class methods are decorated with @classmethod and receive the class as the first argument, conventionally named cls. They cannot see any individual instance, but they can read class attributes and, crucially, create new instances with cls(...). The dominant use case is alternative constructors: Date.from_iso("2026-10-09"), Config.from_env(), User.from_dict(payload). Because they use cls rather than the hard-coded class name, they work correctly for subclasses: Employee.from_dict(d) returns an Employee, not a Person. Real examples: dict.fromkeys(), datetime.fromtimestamp(), int.from_bytes().

Static methods are decorated with @staticmethod and receive nothing special: no self, no cls. They are ordinary functions that happen to live inside the class namespace because they logically belong with it. Use them for validators and helpers such as Account.is_valid_ifsc(code) or unit conversions. If a function never touches self or cls, make it static (or move it to module level). Linters such as pylint will warn about "method could be a function" otherwise.

Decision rule:

• Needs this object's data → instance method.
• Needs the class (to build an instance or read class config) → @classmethod.
• Needs neither, just belongs here conceptually → @staticmethod.

Version note: combining @classmethod with @property to make "class properties" was deprecated in Python 3.11 and removed in Python 3.13. Use a plain class method or a module-level constant instead.

Inheritance lets a new class (the child or subclass) reuse and extend an existing class (the parent, base or superclass). Write class Dog(Animal): and Dog automatically gets every attribute and method of Animal. The relationship should read as "is-a": a Dog *is an* Animal, a SavingsAccount *is a* BankAccount.

Three things a subclass can do:

1. Inherit a method unchanged: it simply uses the parent's version.
2. Override a method: define a method with the same name, and the child's version wins when called on a child instance.
3. Extend a method: override it, but call the parent's version inside using super(), then add extra behaviour.

super() returns a proxy that lets you call methods of the parent class *without naming it*. In Python 3, the zero-argument form super().__init__(...) is all you need inside a method. The most common use is in __init__: the child accepts the parent's parameters plus its own, passes the parent's ones up with super().__init__(...), and then sets its own attributes. If you forget to call super().__init__(), the parent's attributes are never created and you get AttributeError later.

Why super() rather than Animal.__init__(self, ...)? Two reasons: if you rename or re-parent the class, you change one line instead of many; and with multiple inheritance, super() follows the method resolution order (next section), which a hard-coded parent name cannot do.

Useful built-ins:

• isinstance(obj, Cls) — True for the class or any subclass. Prefer it over type(obj) == Cls.
• issubclass(Child, Parent).
• Cls.__bases__ — tuple of direct parents.

Every class in Python 3 implicitly inherits from object, which provides defaults for __init__, __repr__, __eq__ and friends. Keep hierarchies shallow (two or three levels). Deep trees are hard to follow and usually signal that composition (section 11) would be better.

Python allows a class to inherit from more than one parent: class Child(Mother, Father):. When several parents define the same method, which one runs? The answer is the Method Resolution Order (MRO): a linear list of classes that Python searches, in order, until it finds the attribute.

Python computes the MRO using the C3 linearisation algorithm. The rules you need to remember:

• A class always comes before its parents.
• Parents are searched in the order listed in the class statement (left to right).
• Each class appears only once, and object is always last.
• If no consistent ordering exists, Python raises TypeError: Cannot create a consistent method resolution order at class creation time.

Inspect it with ClassName.__mro__ or ClassName.mro(). The classic shape is the diamond: D(B, C) where both B and C inherit from A. The MRO is D → B → C → A → object. Notice that A appears *after* both B and C, not between them. This is what makes super() cooperative: when B.__init__ calls super().__init__(), Python calls the next class in the MRO of the actual instance, which is C, not A. Every class in the chain runs exactly once. This only works if *every* class in the chain calls super(), which is why framework base classes always do.

The practical application of multiple inheritance in Python is the mixin: a small class that provides one piece of reusable behaviour (JSON serialisation, logging, timestamps) and is not meant to be instantiated alone. Django's class-based views (LoginRequiredMixin, ListView) are built entirely this way. Mixins should be listed first in the parent list so their methods take precedence over the main base class.

Rule of thumb: one real base class plus zero or more mixins. If you find yourself drawing a diamond on purpose, stop and consider composition.

Methods whose names start and end with double underscores are called dunder methods (from "double underscore") or magic methods. You never call them directly; Python calls them when you use an operator or a built-in function. len(obj) calls obj.__len__(), a == b calls a.__eq__(b), print(obj) calls obj.__str__(). Implementing them makes your objects feel like built-in types. This is Python's version of operator overloading, and it is the mechanism behind pandas, NumPy and pathlib (Path("a") / "b" is just __truediv__).

The ones every class should consider:

• __repr__ — the *developer* representation, shown in the REPL, in debuggers and inside lists. Convention: return something that looks like the constructor call, e.g. Money(1500, 'INR'). If you define only one of the two, define this one; __str__ falls back to it.
• __str__ — the *user-friendly* representation used by print(), str() and f-strings. Example: Rs 1,500.00.
• __eq__ — defines ==. By default, two objects are equal only if they are the *same* object. Override it to compare by value. Always check the type first and return NotImplemented (not False) for foreign types so Python can try the other operand's __eq__.
• __hash__ — once you define __eq__, Python sets __hash__ to None, so your objects can no longer be dict keys or set members. If you want that, define __hash__ too, based on the same fields as __eq__, and keep those fields immutable.
• __lt__ (and __le__, __gt__, __ge__) — ordering, which unlocks sorted(), min(), max(). Define __eq__ and __lt__, then decorate the class with @functools.total_ordering and the remaining four are generated for you.
• __len__ — makes len() work and also makes the object falsy when empty, because bool() falls back to __len__ when __bool__ is absent.

Others you will meet: __add__ (+), __getitem__ (indexing and iteration), __iter__, __contains__ (in), __enter__/__exit__ (with), __call__ (makes an instance callable).

A property lets you expose a method as if it were a plain attribute. The caller writes account.balance with no parentheses, but behind the scenes a function runs. Properties solve two problems:

1. Validation on assignment. You want temp.celsius = -300 to raise an error. A plain attribute cannot do that; a property with a setter can.
2. Computed, read-only values. rect.area should always equal width * height without you remembering to update a stored field. A property with only a getter is automatically read-only; assigning to it raises AttributeError: property 'area' of 'Rectangle' object has no setter.

Syntax: decorate the getter with @property. To add a setter, define a second function with the same name decorated with @<name>.setter. A @<name>.deleter exists too, but is rarely used. The backing data is usually stored in a single-underscore attribute such as self._celsius.

The big design win is that properties let you start simple and add logic later without breaking callers. In Java you write getters and setters for everything on day one "just in case". In Python you start with a plain attribute, and if validation becomes necessary in year two, you convert it to a property. Every obj.attr in the codebase keeps working. This is why PEP 8 says: do not write trivial get_x() / set_x() methods.

Guidelines:

• Property access should be cheap and side-effect free. If it hits the database or takes seconds, make it a method (fetch_orders()) so the cost is visible to the caller.
• Use functools.cached_property (Python 3.8+) for an expensive value that should be computed once per instance and then stored.
• In __init__, assign through the property (self.celsius = value) so the validation runs on construction too.

Encapsulation means keeping an object's internal state hidden behind a well-defined interface, so that other code cannot depend on details that may change. Java enforces this with private and protected keywords. Python has no access modifiers at all; it uses naming conventions that every Python developer respects:

• name (no underscore) — public. Part of the official interface. Changing or removing it is a breaking change.
• _name (single leading underscore) — "protected" / internal by convention. The message is: "this is an implementation detail; use it only inside this class and its subclasses". Python does not stop you from accessing it from outside, but linters flag it, IDE autocomplete hides it, and from module import * skips it. This is the convention you will use 95% of the time for backing fields behind properties.
• __name (two leading underscores, no trailing underscores) — triggers name mangling. Inside class Account, Python rewrites self.__pin to self._Account__pin. This is not real privacy (you can still reach obj._Account__pin); its purpose is to avoid accidental clashes in subclasses. If a parent and child both define __cache, they get different mangled names and do not overwrite each other. Use it rarely and deliberately.
• __name__ (two leading *and* trailing) — reserved for Python's dunder protocol. Never invent your own.

The Python philosophy is summarised as "we are all consenting adults here": the language trusts developers to respect the underscore. The practical benefits of encapsulation in Python come from properties (section 8), which validate changes, and from offering methods that express intent (account.withdraw(500)) instead of letting callers poke at account._balance directly.

A related tool is __slots__: declare __slots__ = ("owner", "_balance") and instances no longer get a __dict__. Attribute creation is restricted to the listed names, access is faster and memory use drops by roughly 30 to 40 percent per instance. It is used in performance-sensitive code that creates millions of small objects.

An abstract base class (ABC) defines a contract: a set of methods that every subclass *must* implement. It cannot be instantiated itself. Use it when you have several interchangeable implementations of the same idea: payment gateways (Razorpay, PayU, Stripe), storage backends (local disk, S3), notification channels (SMS, email, WhatsApp).

Python provides this through the abc module:

• Inherit from abc.ABC (or set metaclass=ABCMeta).
• Decorate required methods with @abstractmethod. The body can be ..., pass, a docstring, or even a default implementation that subclasses call via super().
• Trying to instantiate the ABC, or a subclass that has not implemented *every* abstract method, raises TypeError: Can't instantiate abstract class ... without an implementation for abstract method .... The error happens at object-creation time, which is far earlier and clearer than a NotImplementedError buried deep in a request handler.

@abstractmethod can be stacked with @property, @classmethod and @staticmethod (put @abstractmethod innermost). ABCs can also contain concrete methods, so they double as a place for shared helper code.

The standard library uses ABCs heavily: collections.abc.Sequence, Mapping, Iterable describe what built-in containers do, and you can register or inherit from them to make your own class behave like a list or dict.

Protocols (Python 3.8+) are the structural alternative. typing.Protocol says "any object that *has* these methods counts", without requiring inheritance. This is duck typing made explicit for type checkers: a class that defines .area() satisfies a Shape protocol even if it never heard of it. Choose a Protocol when you cannot or do not want to modify the implementing classes (third-party objects, built-ins), and an ABC when you own the hierarchy and want runtime enforcement plus shared code.

Composition means building an object *out of* other objects: a Car has an Engine, an Order has a list of OrderLines and has a Customer. The outer object stores the inner ones as attributes and delegates work to them.

Compare with inheritance, which is is-a. Beginners reach for inheritance because it feels like free code reuse, but it creates the tightest coupling in OOP: the child depends on the parent's internal details, and any change in the parent ripples down. Deep hierarchies such as Animal → Mammal → Pet → Dog → GuideDog become impossible to modify safely. The widely-quoted design principle is "favour composition over inheritance" (from the Gang of Four book).

When to use which:

• Inheritance fits when the subclass truly *is* a specialised version of the parent, needs most of its behaviour unchanged, and the hierarchy is shallow. Exceptions (class PaymentError(Exception)), ABC implementations, and framework base classes (class MyView(APIView)) are good examples.
• Composition fits when you are combining capabilities. A NotificationService that has an SMSSender and an EmailSender can swap either one at runtime, mock them in tests, or add a WhatsAppSender without touching any class hierarchy.

Composition also gives you dependency injection for free: pass the collaborators into __init__ instead of creating them inside. Tests can then inject fakes. This is the pattern FastAPI's Depends() and most production services use.

A frequent middle ground is delegation: the outer class forwards a few methods to the inner object (def start(self): return self.engine.start()). If you need to forward *many* methods, implementing __getattr__ to delegate unknown attributes is a known trick, but explicit forwarding is clearer.

Litmus test: if you would be embarrassed to say "a Car is an Engine" out loud, do not inherit.

Look back at Money in section 7: __init__, __repr__, __eq__, __hash__, __lt__ were all written by hand just to store two fields. For classes whose main job is to hold data, Python 3.7 introduced dataclasses (PEP 557) to generate that boilerplate automatically.

Decorate a class with @dataclass and declare fields as annotated class attributes. The decorator reads the annotations and writes __init__, __repr__ and __eq__ for you. Fields with a default value become optional parameters; fields without one are required and must be listed first (unless you use kw_only).

Important options and features:

• field(default_factory=list) — for mutable defaults. Writing items: list = [] directly raises ValueError: mutable default ... use default_factory, which is the dataclass module protecting you from the shared-list bug of section 3.
• frozen=True — makes instances immutable (assignment raises FrozenInstanceError) and automatically hashable, so they can be dict keys and set members. Ideal for value objects such as coordinates, money and config.
• order=True — generates __lt__, __le__, __gt__, __ge__ comparing fields in declaration order, so sorted() works.
• slots=True (Python 3.10+) — generates __slots__ for memory and speed.
• kw_only=True (Python 3.10+) — all fields must be passed by keyword; also lets fields with defaults precede fields without.
• __post_init__ — runs after the generated __init__; use it for validation or derived fields.
• dataclasses.asdict(), astuple(), replace() — convert to a dict (handy for JSON), to a tuple, or create a modified copy of a frozen instance.
• Dataclasses automatically define __match_args__, so they work with positional patterns in match statements (Python 3.10+).

Dataclasses are still ordinary classes: you can add methods, properties, class methods and inheritance. They are the right default for DTOs, configuration, records read from CSV or an API, and test fixtures. When you also need parsing and validation of external input (JSON from an HTTP request), Pydantic v2's BaseModel is the production choice; its syntax is intentionally similar. For pure in-memory data, dataclasses have zero dependencies and are faster.

Every major Python framework is a class hierarchy you plug into. Recognising the patterns from this lecture makes those frameworks far less mysterious.

• Django and SQLAlchemy models — class Order(models.Model): uses inheritance from a framework base class. Fields declared in the class body are class attributes that a metaclass turns into database columns. Order.objects.filter() is a class-level API; order.save() is an instance method. Custom @property methods such as order.total are everywhere in real Django code.
• FastAPI and Pydantic v2 — request and response schemas are classes (class UserCreate(BaseModel):) that look exactly like dataclasses. Validation happens in generated __init__ logic; @field_validator is the Pydantic cousin of __post_init__. Dependency injection via Depends() is composition in action.
• PyTorch — every neural network is class Net(nn.Module): with super().__init__() in its initialiser and an overridden forward(). Layers are composed as attributes; model(x) works because nn.Module implements __call__.
• pandas and NumPy — df["price"] * 1.18 and df[df.city == "Pune"] work through __mul__, __getitem__ and __eq__. len(df) is __len__.
• pathlib — Path("data") / "sales.csv" is __truediv__; Path objects compare and hash by value.
• Exceptions — custom exception hierarchies (class PaymentError(AppError)) let callers catch broad or narrow categories; this is inheritance used exactly as intended.
• Context managers and iterators — with open(...) relies on __enter__/__exit__; custom iterators implement __iter__/__next__.
• Strategy pattern with ABCs — a payments service that supports Razorpay, PayU and Cashfree defines a PaymentGateway ABC and selects a concrete class from configuration. New providers are added without modifying existing code (the Open/Closed principle).
• Configuration objects — a frozen dataclass or Pydantic BaseSettings loaded once at startup replaces a mess of global variables.
• Testing — pytest fixtures often return small objects or fakes that implement the same Protocol as a real dependency, which is only possible because the production code accepts collaborators through composition.

Interviewers at product companies routinely ask candidates to model something small (parking lot, library, splitwise) using exactly these building blocks. The hands-on exercise at the end of this lecture is a practice run.

• Forgetting self — def greet(): inside a class raises TypeError: greet() takes 0 positional arguments but 1 was given. Every instance method's first parameter is the instance. Fix: def greet(self):.
• Mutable class attributes — items = [] in the class body is shared by every instance. Fix: create lists, dicts and sets inside __init__ (self.items = []), or use field(default_factory=list) in dataclasses.
• Not calling super().__init__() — the child defines its own __init__ and the parent's attributes are never created, causing AttributeError in inherited methods. Fix: call super().__init__(...) first, passing the parent's parameters.
• Calling the class instead of creating an instance — Student.greet() fails with a missing self. Fix: Student("Asha").greet().
• Comparing with type(obj) == Cls — breaks for subclasses. Fix: isinstance(obj, Cls).
• Defining __eq__ without __hash__ — objects silently become unhashable; putting them in a set raises TypeError: unhashable type. Fix: define __hash__ on the same immutable fields, or use @dataclass(frozen=True).
• Returning False instead of NotImplemented from __eq__/__lt__ for unrelated types — prevents Python from trying the reflected operation on the other operand. Fix: return NotImplemented.
• Writing Java-style getters and setters — get_name() / set_name() everywhere is noise. Fix: plain attributes first; @property when validation is needed.
• Infinite recursion in a property — the getter does return self.balance instead of return self._balance, calling itself forever (RecursionError). Fix: store the backing value under a different (underscored) name.
• Overusing __double_underscore "private" names — name mangling makes subclasses and tests awkward and gives no real security. Fix: use a single underscore unless you specifically need clash protection.
• Deep inheritance for code reuse — five-level hierarchies that nobody can modify. Fix: compose objects; use mixins sparingly.
• Side effects in __repr__ or properties — logging, I/O or network calls inside them make debugging print statements change behaviour. Keep them pure.
• Abstract class without ABC — decorating with @abstractmethod has no effect unless the class inherits from ABC (or uses ABCMeta). Fix: class Base(ABC):.
• Mutable default argument in a method (def add(self, tags=[])) — same shared-object bug as class attributes. Fix: tags=None then tags = tags or [].

What is the difference between a class and an object in Python?

A class is the blueprint: it defines what attributes and methods a type of thing has. An object (instance) is a concrete value created from that blueprint with its own attribute values. Student is a class; Student("Priya", 21) is an object. One class can produce any number of objects.

What is self in Python and why is it needed?

self is the first parameter of an instance method and refers to the specific object the method is operating on. Python passes it automatically when you call obj.method(), which is equivalent to Class.method(obj). Without it, a method would have no way to know which object's data to read or modify. The name is a convention; the position is what matters.

What is the difference between __init__ and __new__ in Python?

__new__ is the static method that actually allocates and returns a new instance; __init__ then initialises that instance's attributes. You override __init__ almost always and __new__ almost never, except for immutable types (subclassing int or tuple), singletons or metaprogramming.

What is the difference between @classmethod and @staticmethod in Python?

A class method receives the class (cls) as its first argument and is typically used as an alternative constructor or to access class-level state; it respects subclassing. A static method receives no implicit first argument at all and is just a plain function stored in the class namespace for organisational reasons, such as a validator.

Does Python support multiple inheritance?

Yes. A class can list several parents, and Python resolves conflicts using the C3 method resolution order, viewable via ClassName.__mro__. In practice it is used mostly for mixins: small classes that add one capability. Diamond hierarchies work correctly as long as every class in the chain calls super().

How do you make a private variable in Python?

Python has no true private variables. A single leading underscore (_balance) signals "internal, do not touch" by convention. A double leading underscore (__pin) triggers name mangling to _ClassName__pin, which prevents accidental clashes in subclasses but can still be accessed. Real protection comes from exposing properties and methods rather than raw attributes.

What is the difference between __str__ and __repr__ in Python?

__repr__ is the unambiguous developer representation shown in the REPL and inside containers, ideally resembling the constructor call. __str__ is the readable form used by print() and f-strings. If you define only __repr__, str() falls back to it, so define __repr__ first.

When should I use a dataclass instead of a regular class?

Use a dataclass when the class's primary purpose is to hold data and you want __init__, __repr__ and __eq__ generated automatically: records, DTOs, configuration, value objects. Use a regular class when behaviour dominates and the constructor needs custom logic beyond what __post_init__ can handle, or when you are inheriting from a framework base class. For validating external input, Pydantic models are the production choice.

Q1. What are the four pillars of OOP, and how does Python implement each?

Encapsulation: bundling data with methods and hiding internals through underscore conventions and properties. Abstraction: exposing only what callers need, enforced with abstract base classes and Protocols. Inheritance: class Child(Parent) with super() and the MRO. Polymorphism: the same method name behaving differently per class, achieved through method overriding and duck typing, and extended to operators through dunder methods.

Q2. Explain method resolution order. What would D(B, C) with a shared base A print for D.__mro__?

MRO is the ordered list of classes Python searches for an attribute, computed by C3 linearisation. For the diamond it is [D, B, C, A, object]. A class always precedes its parents, parents keep their declared order, and each class appears once, which guarantees super() visits every class exactly once.

Q3. Why does defining __eq__ make a class unhashable, and how do you fix it?

Equal objects must have equal hashes. The default __hash__ is identity-based, which would violate that rule once __eq__ compares by value, so Python sets __hash__ = None. Fix it by defining __hash__ over the same fields used in __eq__ (which should be immutable), or use @dataclass(frozen=True).

Q4. What is the difference between composition and inheritance, and when do you prefer each?

Inheritance models "is-a" and shares implementation through the class hierarchy; composition models "has-a" by storing collaborator objects as attributes. Prefer composition by default because it has looser coupling, supports swapping collaborators at runtime and simplifies testing through dependency injection. Use inheritance for genuine specialisation, exception hierarchies and framework base classes.

Q5. How does super() work with multiple inheritance?

super() does not mean "my parent"; it means "the next class after me in the MRO of the instance being used". In a diamond, B's super().__init__() may call C.__init__, not A.__init__. This cooperative behaviour requires every class in the chain to call super() and to accept and forward arguments it does not use, usually with **kwargs.

Q6. What does @property do and when is it better than a method?

It turns a method into an attribute-style accessor, optionally with a setter for validation. Use it for cheap, side-effect-free values that conceptually are attributes (area, full name, formatted balance). Use a regular method when the operation is expensive, has side effects or takes arguments, so the cost is explicit to the caller.

Q7. What is an abstract base class and what happens if a subclass does not implement all abstract methods?

An ABC (from the abc module) declares methods that subclasses must implement with @abstractmethod. Python refuses to instantiate the ABC itself or any subclass that leaves an abstract method unimplemented, raising TypeError at construction time, which catches missing implementations early.

Q8. What are __slots__ and why would you use them?

__slots__ is a class attribute listing the allowed instance attribute names. Instances then have no __dict__, which lowers memory per object significantly and speeds up attribute access. Use it for classes instantiated in very large numbers, such as rows, nodes or events. Trade-offs: you cannot add attributes dynamically, and multiple inheritance with slots needs care.

Q9. What is duck typing, and how does typing.Protocol relate to it?

Duck typing means Python cares about what an object can do, not what class it belongs to: if it has .read(), it can be used as a file. Protocol makes this explicit for static type checkers: a class satisfies a Protocol by having the right methods, without inheriting from it. @runtime_checkable additionally allows isinstance() checks.

Q10. How would you implement a singleton in Python, and should you?

Override __new__ to return a stored instance, or use a module-level object, which is the simplest and most Pythonic approach because modules are imported once. Singletons are often an anti-pattern because they hide dependencies and complicate testing; injecting a shared instance through composition is usually better.

Build a small library system that exercises everything from this lecture: an abstract LibraryItem base class with concrete Book and DVD subclasses, dunder methods for printing, equality and sorting, a @property with validation, a @classmethod alternative constructor, a @staticmethod validator, a frozen Member dataclass, and a Library class that uses composition to hold items and members and expose len() and in.

Requirements:

1. LibraryItem (ABC): fields item_id, title, year; abstract property loan_days; abstract method describe(); concrete methods checkout(member) and return_item(); __eq__/__hash__ by item_id; __lt__ by title so items sort alphabetically.
2. Book(LibraryItem): adds author and isbn, validates the ISBN with a static method, loan_days = 14, and a from_csv_row() class method.
3. DVD(LibraryItem): adds minutes, loan_days = 7.
4. Member: a frozen dataclass with member_id, name, city.
5. Library: stores items in a dict keyed by item_id; supports add(), find(item_id), available(), len(library), item in library and iteration in sorted order.

Run the file with python library.py and compare your output with the comments at the bottom. Then extend it: add an EBook class with unlimited copies, or a Fine calculation using datetime.

• A class is a blueprint; an instance is an object built from it. __init__ initialises attributes and self is the instance being operated on.
• Instance attributes (self.x) are per object; class attributes are shared. Never use a mutable class attribute as a per-instance default.
• Instance methods take self; @classmethod takes cls and is ideal for alternative constructors; @staticmethod takes neither and holds helpers.
• Inheritance models "is-a"; super() calls the next class in the MRO, which Python computes with C3 linearisation and exposes via __mro__. Use mixins sparingly.
• Dunder methods (__repr__, __str__, __eq__, __hash__, __lt__, __len__, __add__, __getitem__) let your objects work with operators and built-ins; @total_ordering fills in comparison gaps.
• @property gives attribute syntax with validation and computed values; cached_property memoises expensive ones.
• Encapsulation in Python is by convention: _internal, __mangled, and __slots__ for fixed, memory-efficient attributes.
• Abstract base classes (ABC, @abstractmethod) enforce contracts at instantiation time; Protocol does so structurally for type checkers.
• Prefer composition ("has-a") over deep inheritance; inject collaborators for flexibility and testability.
• Dataclasses (Python 3.7+) generate __init__, __repr__ and __eq__; use field(default_factory=...), frozen=True, order=True, slots=True and kw_only=True (3.10+) as needed.

Next lecture: Modules, Packages, Dependencies & Project Structure