OOP Part 1 | Class & Object | Data Science Mentorship Program(DSMP) 2022-23

TL;DR

Python’s built-in types behave like objects: each type has its own attributes and methods, and calling a missing method triggers attribute errors.

Briefing Cornell Notes

Briefing

Object-oriented programming (OOP) becomes understandable once it’s treated as a relationship between “classes” (blueprints) and “objects” (instances), and once the special mechanics—especially constructors, magic methods, and the meaning of `self`—are made practical through code. The session’s core message is that Python’s built-in types already behave like objects, and the same machinery can be used to build custom data types that feel natural to use, extend, and even integrate with operators like `+` and `*`.

The walkthrough starts with a quick Python reality check: lists, strings, tuples, dictionaries, sets, and even numbers act like objects. Attempts to call methods that don’t exist (like `append` on a string) trigger errors such as “object has no attribute,” reinforcing that Python’s data types share an object model. From there, the course frames OOP as the “object-oriented” relationship between an object and the rules it follows—because the term OOP itself implies a structured relationship between entities.

To make the concept stick, the session uses a real-world story about building a LinkedIn-like startup. Procedural, top-to-bottom coding worked until the codebase grew and adding new features became painful. After learning OOP, the same kind of application work accelerated because behavior and data could be organized into reusable structures rather than scattered logic.

The plan for the week is then laid out: three days focused on OOP basics and practical coding, followed by deeper concepts like encapsulation, polymorphism, inheritance, and abstraction, and finally a project plus interview-focused discussion.

In the coding portion, the instructor builds an “ATM” banking application using a class. The class stores key data (a customer’s `pin` and `balance`) and exposes behaviors through methods such as `menu`, `create_pin`, `change_pin`, `check_balance`, and `withdraw`. The session emphasizes that class code doesn’t run just because it exists; it runs when an object is created. That’s where the constructor comes in.

A major turning point is the explanation of the constructor as a “magic method” that runs automatically when an object is instantiated. The constructor initializes attributes like `pin` and `balance` and can also trigger setup logic (like showing the ATM menu) without requiring explicit calls. This is contrasted with normal methods, which only execute when invoked by user actions.

The session also drills into the meaning of `self` as the hidden link to the current object. Because class members shouldn’t directly call each other across methods without an object context, `self` enables one method to access another method and the object’s stored attributes safely. The instructor even demonstrates that `self` corresponds to the current object’s identity in memory.

Finally, the session escalates from “ATM” to building custom numeric types. It introduces a `Fraction` class with a parameterized constructor (taking numerator and denominator) and uses magic methods to control printing (`__str__`) and operator behavior. By implementing magic methods like `__add__`, `__sub__`, `__mul__`, and `__truediv__`, Python can automatically support expressions such as `fr1 + fr2` and return a new `Fraction` object with correct numerator/denominator logic. The takeaway is that OOP isn’t just organization—it’s a power tool for creating data types that behave like first-class citizens in Python, enabling operator overloading and richer abstractions for real-world applications.

Cornell Notes

The session argues that OOP in Python becomes clear when “classes” are treated as blueprints and “objects” as instances that follow those blueprints. It uses an ATM example to show how a class stores data (like `pin` and `balance`) and exposes behaviors through methods (like `create_pin`, `change_pin`, `check_balance`, and `withdraw`). A constructor (a magic method) runs automatically when an object is created, so initialization logic doesn’t require manual calls. The meaning of `self` is central: it represents the current object and lets methods access the object’s attributes and coordinate with other methods. The session ends by building a custom `Fraction` type and using magic methods to support printing and operators such as `+`, `-`, `*`, and `/`.

Why does Python treat built-in types like lists and strings as “objects,” and what does that imply for OOP?

The session demonstrates that calling methods that don’t exist on a type raises attribute errors (e.g., `append` works on lists but not on strings). That behavior reflects Python’s object model: each data type has its own set of attributes and methods. The implication for OOP is that if built-ins follow the object model, custom types can be built the same way—by defining a class (rules) and then creating objects (instances) that use those rules.

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

A class is the blueprint: it defines what data (attributes) and behaviors (methods) exist. An object is an instance of that class: it holds specific values for the attributes and can execute the methods defined in the class. In the ATM example, the class defines `pin` and `balance` plus methods like `menu` and `withdraw`, while each ATM object created by the program has its own `pin` and `balance` values.

How does the constructor change the way initialization works?

The constructor is a special magic method that runs automatically when an object is created. In the ATM example, creating an ATM object triggers initialization of `pin` and `balance` (e.g., setting `balance` to zero) and can also trigger setup logic like showing the menu. Normal methods don’t run automatically; they execute only when called by code (often in response to user input).

What does `self` mean, and why is it necessary for method-to-method communication?

`self` is the current object instance passed implicitly to methods. The session ties it to the idea that class members should access each other through the object context. For example, the constructor can call `menu` using `self.menu()` rather than calling `menu` directly. The session also shows that `self` corresponds to the object’s identity (an address-like value), and removing `self` breaks access because the method no longer receives the object context it needs.

How do magic methods enable operator overloading in a custom class like `Fraction`?

Magic methods let Python map operators and built-in behaviors to class logic. The session implements `Fraction` so that printing works via `__str__` (so `print(fr)` shows a formatted fraction), and arithmetic works via methods like `__add__`, `__sub__`, `__mul__`, and `__truediv__`. With these in place, expressions such as `fr1 + fr2` automatically call the corresponding magic method and return a new `Fraction` with computed numerator and denominator.

What’s the key distinction between “function” and “method” in this OOP context?

A function is independent and exists outside a class. A method is defined inside a class and is called on an object (so it receives `self`). The session uses examples like `append` on a list as a method (inside the list class) and `len` as a function-like behavior associated with the type’s implementation, emphasizing that inside-class behavior is method behavior.

Review Questions

In the ATM example, which parts of the class represent data (attributes) and which parts represent behaviors (methods)?
Why does the constructor run without an explicit call when you create an object, and how does that differ from calling `menu` or `withdraw`?
When implementing `Fraction`, what logic must `__add__` follow to correctly add two fractions, and how does `__str__` affect what `print()` displays?

Key Points

1
Python’s built-in types behave like objects: each type has its own attributes and methods, and calling a missing method triggers attribute errors.
2
A class is a blueprint defining attributes (data) and methods (behaviors); an object is an instance that stores specific values and can run those methods.
3
Object creation triggers the constructor automatically, making initialization logic run at instantiation time rather than requiring manual calls.
4
`self` is the current object instance; it enables methods to access the object’s attributes and to call other methods safely within the same instance.
5
Magic methods (like `__str__` and `__add__`) let custom classes integrate with Python features such as printing and operators.
6
Operator overloading in `Fraction` works by implementing arithmetic magic methods that compute new numerator/denominator results and return new objects.
7
Class member communication is typically routed through the object context (`self`) rather than direct cross-calls between methods without an instance.

Highlights

Lists and strings both act like objects in Python; trying to use a list-only method on a string produces an “object has no attribute” error.

The constructor is a magic method that runs automatically whenever an object is created, making initialization and setup logic happen without explicit calls.

`self` is not just a naming convention—it represents the current object instance, enabling methods to access attributes and coordinate with other methods.

By implementing magic methods, a custom `Fraction` type can support `print(fr)` formatting and arithmetic like `fr1 + fr2` directly.

The ATM example demonstrates the full OOP flow: define class → create object → methods execute only when called (often after user input).

Topics

Object-Oriented Programming
Classes and Objects
Constructor and Self
Magic Methods
Operator Overloading