Python OOPs Concepts | Classes, Objects, Inheritance, Polymorphism Explained | Python Tutorial for Beginners 2026

What is OOP (Object-Oriented Programming) in Python?

Object-Oriented Programming is a way of organising code around objects — self-contained bundles that hold both data (attributes) and the functions that operate on that data (methods) together, instead of keeping data and logic as separate, loosely-related things floating around a script. A BankAccount object holds its own balance and comes with its own deposit() and withdraw() methods bolted directly to it — the data and the behaviour that's allowed to touch that data live in the same place, on purpose.

In Python, you define the blueprint for these objects using the class keyword. A class is the template; an object (or instance) is a specific thing built from that template. class Dog: defines what a dog generally looks like — it has a name, a breed, it can bark — and my_dog = Dog("Bruno", "Labrador") creates one specific, real dog object following that template, with its own actual name and breed values, distinct from any other Dog object you create.

Here's something worth saying plainly, since a lot of tutorials skip it: Python doesn't force you to use OOP. You can write a completely functional Python script using nothing but plain functions and dictionaries, and plenty of good scripts do exactly that. OOP earns its complexity when you're modelling something with genuine identity and internal state that persists and changes over time — a user account, a game character, a database connection — not for every single script you write. My honestly opinionated take: I've seen more damage done by forcing unnecessary classes onto a 40-line script than by beginners avoiding OOP too long. Learn it properly, then use judgment about when it actually earns its place.

This guide covers class and object mechanics, the self keyword and why it exists, the __init__ constructor, and the four pillars traditionally used to describe OOP — encapsulation, inheritance, polymorphism, and abstraction — with the exact errors you'll run into along the way, including the notorious TypeError: missing 1 required positional argument: 'self'.

History — How Python's OOP Support Developed

Python has supported classes since its very first release, but the specific way object-oriented code is written in Python has genuinely evolved, with one particularly significant unification that changed how the whole language thinks about types.

▶
1991 — Python 0.9.0 — Classes, inheritance, and exception handling as classes were present from Python's first public release — Guido van Rossum's design notes describe classes as a core feature from the very beginning, not a later addition.
▶
Early-to-mid 1990s — Old-Style Classes — Early Python had a distinction between 'old-style' classes (which didn't inherit from a common root type) and built-in types like int or list, which were implemented differently in C and behaved with subtly different rules — a genuine wart in the language's early design.
▶
2002 — Python 2.2 (PEP 252, 253) — Introduced 'new-style' classes, unifying user-defined classes and built-in types under a single object model, all ultimately inheriting from a common object base type. This was a foundational change that made Python's type system genuinely consistent.
▶
2008 — Python 3.0 — Made new-style classes the ONLY kind — every class in Python 3 automatically inherits from object, whether you write class Dog(object): or simply class Dog:, finally eliminating the old-style/new-style distinction entirely.
▶
2015 — Python 3.5 — Introduced typing.NamedTuple and enhanced dataclass-adjacent patterns, offering lighter-weight alternatives to full classes for simple data-holding structures.
▶
2018 — Python 3.7 (PEP 557) — Introduced the @dataclass decorator, dramatically reducing the boilerplate needed for classes whose main job is holding structured data, auto-generating __init__, __repr__, and __eq__ methods based on class-level type annotations.
▶
2026 — Current state — Full classical OOP support — classes, inheritance, multiple inheritance, abstract base classes via the abc module, and dataclasses for lighter-weight cases — all coexist as options, letting Python developers choose exactly how much OOP ceremony a given problem actually needs.

Key Characteristics of Python Classes and Objects

Here are the 12 things worth knowing precisely about how Python's object model actually works:

🏗️

Defined with class

class Dog: followed by an indented block defines a class. By convention, class names use PascalCase (Dog, BankAccount), distinguishing them visually from function and variable names, which use snake_case.

🔧

__init__ Is the Constructor

The __init__ method runs automatically whenever a new object is created from the class, typically used to set up the object's initial attribute values based on arguments passed at creation time.

🫴

self Refers to the Specific Instance

Every regular method's first parameter, conventionally named self, refers to the specific object the method was called on — it's how a method accesses and modifies that particular object's own attributes.

📦

Objects Hold Their Own State

Two objects created from the same class are completely independent — changing one object's attribute has zero effect on another object of the same class, unless they're explicitly sharing a mutable class-level attribute.

🧬

Supports Inheritance

A class can inherit from another class, automatically gaining its attributes and methods while being free to override or extend them — class Puppy(Dog): builds on everything Dog already defines.

🎭

Supports Polymorphism

Different classes can implement the same method name with different behaviour, letting code written against a common interface work correctly regardless of the specific object's exact type.

🔒

Encapsulation via Naming Convention

Python doesn't enforce true private attributes the way Java does — a leading underscore (_balance) signals 'internal use, don't touch directly' by convention, while double underscore (__balance) triggers name mangling for a stronger (but still not absolute) form of privacy.

🎩

Dunder Methods Customise Behaviour

Methods like __str__, __eq__, __len__, and __add__ (all with double underscores, hence 'dunder') let a custom class integrate with Python's built-in operators and functions — print(), ==, len(), + — behaving naturally rather than needing special custom syntax.

🏛️

Class Attributes vs Instance Attributes

Attributes defined directly inside the class body (outside any method) are shared across every instance by default. Attributes assigned via self.x = ... inside __init__ belong to that specific instance alone.

🧪

abc Module Enables True Abstraction

The abc module's ABC base class and @abstractmethod decorator let you define a class that cannot be instantiated directly and forces subclasses to implement specific methods, genuinely enforced at runtime.

🔗

Multiple Inheritance Is Supported

Unlike Java, a Python class can inherit from more than one parent class simultaneously: class FlyingFish(Fish, Bird): — resolved via a defined, predictable method resolution order (MRO).

🎯

Everything in Python Is Actually an Object

Integers, strings, functions, and even classes themselves are objects in Python, all ultimately inheriting from the base object type — this uniformity is why type(5) returns <class 'int'>, treating even a plain number as an instance of a class.

How an Object Gets Created and Used — Flowchart

Creating an object and calling a method on it goes through a specific, precise sequence — Python allocates memory, runs your constructor, and then routes every method call back to that exact object via self. Here's that full pipeline traced through.

📝 Dog("Bruno", "Labrador") CalledClass used like a function

class called

🧱 New Object AllocatedEmpty instance created in memory

constructor invoked

🔧 __init__ Runs Automaticallyself, "Bruno", "Labrador" bound

runs body

📥 Attributes Set on selfself.name = "Bruno", etc.

construction complete

📤 Fully Formed Object ReturnedAssigned to my_dog variable

later in code

📞 my_dog.bark() CalledMethod called on the object

Python auto-binds

🫴 self Bound to my_dogPython passes the object automatically

runs using that instance's data

▶️ Method Body ExecutesUsing self.name, self.breed, etc.

Code Execution Flow — from source to output

Key insight: step 7 is the part beginners most often miss — when you write my_dog.bark(), you never actually pass my_dog as an argument yourself. Python does that automatically, behind the scenes, which is exactly why bark(self): needs that self parameter in its definition even though you never see it supplied at the call site.

How OOP Actually Works — self, init, and the Error They Explain

Three things separate someone who's copied a class template from someone who actually understands Python's object model: knowing exactly what self is and why it's required, understanding what __init__ genuinely does (and doesn't do), and recognising the specific error that appears the moment either of these is misunderstood.

🫴 self — Not Magic, Just an Explicit Parameter

Here's the thing that makes self click for a lot of people: it's not a keyword, and it's not special syntax. It's a completely ordinary parameter name — Python could work exactly the same if you called it this or instance instead, though breaking the self convention would confuse literally every other Python developer who reads your code. When you write my_dog.bark(), Python automatically translates that, internally, into something functionally equivalent to Dog.bark(my_dog) — the object you called the method on gets passed as the first argument, automatically, every single time. That's the entire mechanism. self is just the name conventionally given to that first, automatically-supplied argument.

💥 The Classic Error — Forgetting self

Write a method without the self parameter — def bark(): instead of def bark(self): — and calling my_dog.bark() raises TypeError: bark() takes 0 positional arguments but 1 was given. This confuses nearly everyone the first time, because you genuinely didn't pass any arguments at the call site. But Python still automatically supplies my_dog as that first argument regardless of whether your method's signature has room for it — the method just wasn't written to accept it. This is one of the most common beginner OOP errors, and understanding exactly why it happens (rather than just memorising 'always add self') is what actually prevents it from recurring in slightly different forms later.

🔧 init — Setup, Not Creation

__init__ is commonly called 'the constructor,' but that's a slight simplification worth being precise about: the object has technically already been created (allocated in memory) by the time __init__ runs — __init__'s job is initialising that already-existing object's starting state, not creating the object itself (that's technically a separate, rarely-touched method called __new__). In practice, this distinction rarely matters day to day, but it explains why __init__ never has a return statement returning a value — its whole job is setting attributes on self, and returning anything other than None from __init__ actually raises TypeError: __init__() should return None.

Simple rule to remember: every regular method needs self as its first parameter, Python supplies that argument automatically whenever you call a method on an object, and __init__ is where you set up an object's starting attributes using self.attribute_name = value, never returning anything from it.

The Four Pillars of OOP — Key Differences

Encapsulation, inheritance, polymorphism, and abstraction are the four concepts traditionally used to describe what makes a language 'object-oriented.' Here's what each one actually means in concrete Python terms.

Pillar	Core Idea	Python Mechanism	Example
Encapsulation	Bundle data and the methods that operate on it together, controlling access	Underscore naming conventions (_x, __x), properties	class BankAccount: self._balance — internal, accessed via methods
Inheritance	A class reuses and extends another class's attributes and behaviour	class Child(Parent): syntax	class SavingsAccount(BankAccount): adds interest logic on top
Polymorphism	Different classes respond to the same method call in their own way	Method overriding, duck typing	Both Dog and Cat implement speak(), called identically
Abstraction	Hide internal complexity behind a simple, well-defined interface	abc module, ABC base class, @abstractmethod	class Shape(ABC): forces every subclass to implement area()

OOP Implementation — Python vs Other Languages

Python's OOP model is genuinely more relaxed than Java's or C++'s in several specific, deliberate ways, and the contrast explains a lot about how Python code tends to look different from enterprise-style OOP code.

Feature	Python	Java	C++	JavaScript
True private attributes	❌ Convention only (_x, name mangling for __x)	✅ Enforced with private keyword	✅ Enforced with private keyword	✅ Enforced with # (ES2022+) or closures
Multiple inheritance	✅ Fully supported, with defined MRO	❌ Not for classes (interfaces only)	✅ Supported, genuinely complex	❌ Not natively (mixins simulate it)
Abstract classes	✅ Via abc module, opt-in	✅ Native abstract keyword	✅ Via pure virtual functions	❌ Not native, simulated via convention
Method overloading	❌ Not supported natively	✅ Supported	✅ Supported	❌ Not supported natively
Constructor overloading	❌ Not directly (use default args instead)	✅ Supported	✅ Supported	❌ Not directly
Access modifier enforcement	Convention-based, not compiler-enforced	Compiler-enforced	Compiler-enforced	Runtime-enforced for # fields
'this'/'self' explicitness	Explicit first parameter, always visible	Implicit this, invisible in method signature	Implicit this, invisible in method signature	Implicit this, context-dependent behaviour

Here's my honestly opinionated take: Python making self an explicit, visible parameter — rather than an implicit, invisible one like Java's this — is one of its most underrated teaching advantages. It forces every Python developer to actually see, in the method signature itself, exactly how an object gets access to its own data, rather than treating it as invisible magic. I've watched people coming from Java genuinely struggle to explain how this works internally, while Python developers who've internalised self as 'just the object, passed as the first argument, automatically' tend to have a noticeably clearer mental model of what's actually happening.

Advantages and Disadvantages of Python's OOP Approach

Python's relaxed, convention-based approach to OOP is a genuine trade-off — flexible and fast to write, but leaning heavily on developer discipline rather than compiler enforcement.

✅ Advantages

Minimal Boilerplate Compared to Java/C++No mandatory access modifier keywords on every attribute, no separate header/implementation files — a working Python class is often a fraction of the lines an equivalent Java class needs.

Multiple Inheritance Without Interface WorkaroundsPython lets a class genuinely inherit from several parent classes directly, unlike Java's single-inheritance-plus-interfaces model, with a clear, predictable method resolution order handling any conflicts.

Explicit self Makes the Object Model TransparentSeeing self as a real, visible parameter in every method signature demystifies exactly how instance methods access their own object's data, rather than hiding it as invisible language magic.

Duck Typing Enables Flexible PolymorphismPython doesn't require classes to share a common explicit interface to be used interchangeably — if an object has the right methods, it works, regardless of formal inheritance relationships.

Dunder Methods Integrate Naturally with Built-insCustom classes can support +, ==, len(), and print() through dunder methods, making user-defined types feel like genuine first-class citizens alongside Python's built-in types.

Opt-In Complexity via dataclasses and abcSimple data-holding classes can use @dataclass to skip boilerplate entirely, while genuinely complex hierarchies can opt into strict enforcement via the abc module — Python doesn't force one level of ceremony on every class.

❌ Disadvantages

No True Access Control EnforcementPrivate attributes are purely a naming convention (_x) or a mild name-mangling deterrent (__x) — nothing in Python actually PREVENTS external code from directly touching an attribute meant to be internal.

self Must Be Manually Included Every TimeForgetting self as the first parameter in every method definition is a genuinely common, recurring beginner mistake, producing a confusing TypeError the first several times it happens.

No Native Method or Constructor OverloadingUnlike Java or C++, you can't define multiple versions of __init__ or a method with different parameter types — Python developers work around this with default arguments and manual type checking instead.

Multiple Inheritance Can Get Genuinely ComplexWhile supported, deep or tangled multiple-inheritance hierarchies can make the method resolution order genuinely hard to reason about, especially in the classic 'diamond problem' shape.

Runtime Errors Instead of Compile-Time ChecksA missing method, wrong attribute name, or forgotten self isn't caught until that specific line actually executes, unlike statically-typed OOP languages that catch many such errors before the program ever runs.

Overuse of Classes for Simple ScriptsPython's flexibility doesn't stop developers from over-engineering small scripts with unnecessary class hierarchies where a handful of plain functions would have been simpler and clearer.

Python's Object Model Architecture

The diagram below shows how classes, instances, and inheritance actually relate to each other in Python's underlying object model — from your class definition down to how attribute lookup actually resolves at runtime.

Class Definition
class Dog:Class-level attributesMethod definitions (self, ...)
Instantiation
Dog("Bruno", "Labrador")__new__ allocates the object__init__ initialises its attributes
Instance Namespace
self.name, self.breedUnique per objectChecked FIRST for attribute lookup
Class Namespace
Shared class-level attributesMethod definitionsChecked if not found on the instance
Inheritance Chain (MRO)
Parent class(es)Grandparent class(es)Checked in Method Resolution Order
Base object Type
Root of every Python classProvides default __repr__, __eq__, etc.Final fallback in attribute lookup
Architecture Diagram

OOP in Practice — From a Basic Class to Inheritance and the Classic Error

Here's a complete, working example covering a base class, inheritance, method overriding, and encapsulation — followed by the exact self-related error and its fix.

🐍 Pythonoop_example.py

class Animal:
    def __init__(self, name, sound):
        self.name = name
        self._sound = sound   # single underscore = internal convention

    def speak(self):
        return f"{self.name} says {self._sound}"

    def __str__(self):
        return f"Animal({self.name})"


class Dog(Animal):              # inheritance
    def __init__(self, name, breed):
        super().__init__(name, sound="Woof")
        self.breed = breed

    def speak(self):            # polymorphism — overriding the parent method
        return f"{self.name} the {self.breed} barks: Woof!"


animals = [Animal("Generic Creature", "..."), Dog("Bruno", "Labrador")]
for a in animals:
    print(a.speak())    # each object responds in its own way

print(animals[1])       # uses __str__ automatically

Output

Generic Creature says ... Bruno the Labrador barks: Woof! Animal(Bruno)

Now the classic beginner mistake — forgetting self — reproduced exactly:

🐍 Pythonmissing_self.py

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

    def bark():          # BUG: missing self
        print("Woof!")

my_dog = Dog("Bruno")
my_dog.bark()

Output

Traceback (most recent call last): File "missing_self.py", line 8, in <module> my_dog.bark() TypeError: bark() takes 0 positional arguments but 1 was given

Practice This Code — Live Editor

Line-by-Line Explanation

▶
class Dog(Animal): — This is inheritance. Dog automatically gains everything Animal defines, and can add its own attributes or override methods.
▶
super().__init__(name, sound="Woof") — Calls the parent class's __init__ to reuse its setup logic, rather than duplicating self.name = name again inside Dog.
▶
def speak(self): defined again inside Dog — This is polymorphism through method overriding. Calling .speak() on an Animal object and a Dog object runs genuinely different code, even though the method is called identically in both cases.
▶
def __str__(self): — A dunder method that customises what print(animals[1]) actually displays, letting a custom object integrate naturally with Python's built-in print() function instead of showing a default, unhelpful memory address.
▶
def bark(): without self — The fix is simply adding self as the first parameter: def bark(self):. Python was already automatically supplying my_dog as an argument the moment my_dog.bark() was called; the method definition just wasn't written to receive it.

Where OOP Actually Earns Its Place — Real-World Applications

OOP isn't just an academic exercise — it's how a substantial share of real, professional Python code is genuinely structured:

▶
🌐 Django and Web Framework Models — Every Django database table is defined as a Python class inheriting from models.Model, with fields as class attributes and custom business logic as methods — genuinely OOP-driven, end to end.
▶
🤖 Machine Learning Model Classes — PyTorch's nn.Module and scikit-learn's estimator classes are built entirely around inheritance and method overriding — a custom neural network is a class inheriting from nn.Module, overriding its forward() method.
▶
🎮 Game Development — Game entities (Player, Enemy, Projectile) are classic OOP use cases, typically sharing a common base class for shared behaviour (position, health) while each subclass overrides methods for its specific behaviour.
▶
🏦 Business Domain Modelling — Real-world business entities — Customer, Order, Invoice, BankAccount — map naturally onto classes, with encapsulation keeping validation logic (like preventing a negative balance) tightly coupled to the data it protects.
▶
🧪 Custom Exception Hierarchies — Well-designed applications define their own exception classes inheriting from Exception, letting calling code catch specific, meaningful error types (InsufficientFundsError) rather than generic ones.
▶
🔌 Building Reusable Libraries and APIs — Library authors use abstract base classes (via the abc module) to define a required interface, forcing anyone extending the library to implement specific methods, genuinely enforced at runtime.
▶
📊 GUI Application Development — Tkinter, PyQt, and similar GUI frameworks are built around widget classes, and application-specific windows and dialogs are typically written as classes inheriting from the framework's base widget classes.
▶
☁️ API Client Wrappers — Wrapping a third-party API often means defining a class that holds connection state (API key, session) as instance attributes, with methods for each API endpoint — a natural fit for encapsulation.

Why OOP Is Worth the Real Effort It Takes

OOP has a genuine learning curve, and it's fair to be honest about that rather than pretending classes are just 'functions with extra steps.' Here's why the investment pays off:

▶
🏗️ It's How Most Real Frameworks Are Structured — Django, PyTorch, Tkinter, and most substantial Python libraries expect you to write classes that inherit from their base classes. Not understanding OOP genuinely blocks effective use of these tools.
▶
💼 It's a Core Interview Topic at Every Level — Explaining the four pillars, designing a small class hierarchy on a whiteboard, or predicting the output of an inheritance example are all standard, recurring interview scenarios, from fresher to senior roles.
▶
🧠 It Teaches a Genuinely Different Way to Model Problems — Thinking in terms of 'what are the things in this system, and what do they know and do' is a distinct, valuable design skill separate from procedural, top-to-bottom scripting.
▶
🔧 It's the Foundation for Design Patterns — Nearly every classic software design pattern (Factory, Observer, Strategy, Singleton) is expressed in terms of classes, inheritance, and polymorphism — OOP fluency is a genuine prerequisite for understanding them.
▶
🐛 Understanding self Prevents an Entire Class of Bugs — The forgotten-self TypeError, along with confusion about instance versus class attributes, accounts for a real share of early OOP debugging time — properly understanding the mechanism eliminates both almost entirely.
▶
🇮🇳 It's a Major, Heavily Weighted Topic in Indian CS Curricula — OOP concepts, often taught first in C++ or Java before Python, are consistently one of the most heavily tested topics in Indian engineering college exams and campus placement technical rounds.

A Closer Look — Encapsulation and Inheritance Patterns

Two of the four pillars deserve a bit more concrete detail, since they show up constantly in real class design decisions.

▶
Public attributes (no underscore) — self.name — freely accessible and modifiable from outside the class, no restriction implied at all. The default, most common case.
▶
Protected attributes (single underscore) — self._balance — a convention signalling 'this is internal, treat it as implementation detail, don't touch it directly from outside the class,' but Python enforces absolutely nothing here; it's purely a courtesy signal to other developers.
▶
Private attributes (double underscore) — self.__balance — triggers Python's name mangling, internally renaming the attribute to _ClassName__balance. This makes accidental external access noticeably harder (you'd need to know the mangled name), though it's still technically reachable, not truly private in the Java sense.
▶
@property for controlled access — Using the @property decorator lets you expose what looks like a plain attribute externally (account.balance) while actually running validation logic behind the scenes internally — the cleanest, most Pythonic form of real encapsulation.
▶
Single inheritance — class SavingsAccount(BankAccount): — the standard, most common inheritance pattern, extending one parent class.
▶
Multiple inheritance — class FlyingFish(Fish, Bird): — inheriting from more than one class at once, resolved via Python's Method Resolution Order (MRO), calculated using the C3 linearization algorithm, viewable via ClassName.__mro__.
▶
super() for cooperative inheritance — Calling super().__init__(...) lets a subclass extend its parent's setup logic rather than duplicating or completely replacing it, and correctly participates in more complex multiple-inheritance chains too.

Encapsulation Level	Syntax	Enforcement	Typical Use
Public	self.name	None — fully open	Default for most straightforward attributes
Protected (convention)	self._name	None — courtesy signal only	Internal implementation details other devs shouldn't rely on
Private (name-mangled)	self.__name	Weak — requires knowing the mangled name	Discouraging accidental external access more strongly
Property-based	@property decorated method	Genuine — runs validation logic on access/assignment	Controlled, validated access presented as a plain attribute

Python OOPs Concepts — Interview Questions

These are among the most consistently asked Python interview questions across every experience level, from campus placements to senior backend interviews.

__new__ is responsible for actually creating and returning a new instance of the class — it's rarely overridden directly in typical code. __init__ runs immediately after __new__ has created the object, and its job is initialising that already-existing object's starting attribute values. __init__ never returns a value (must implicitly return None), while __new__ must return the newly created instance.

Encapsulation — bundling data and methods together, restricting direct access via naming conventions (self._balance). Inheritance — a class reusing and extending another class's behaviour (class Dog(Animal):). Polymorphism — different classes responding to the same method call differently (Dog and Cat both implementing speak() distinctly). Abstraction — hiding implementation complexity behind a simple required interface (an ABC forcing subclasses to implement area()).

This happens when a method is defined without self as its first parameter, but Python still automatically passes the calling object as an argument whenever the method is called on an instance. Since the method's definition has no parameter to receive that automatically-supplied argument, Python reports a mismatch between the number of arguments expected (0, as written) and the number actually supplied (1, the object itself).

A class attribute is defined directly inside the class body, outside any method, and is shared across every instance of that class by default — changing it on the class affects all instances that haven't overridden it individually. An instance attribute is defined via self.attribute = value, typically inside __init__, and belongs uniquely to that specific object, completely independent from other instances of the same class.

No. Python has no genuine access-control enforcement. A single leading underscore (_name) is purely a naming convention signalling 'internal use, don't rely on this externally' — nothing prevents access. A double leading underscore (__name) triggers name mangling, internally renaming the attribute to _ClassName__name, making accidental external access harder but still technically possible if you know the mangled name.

super() returns a proxy object that lets you call methods from a class's parent (or, more precisely, the next class in the Method Resolution Order) without hardcoding the parent's name directly. It's preferred because it correctly participates in Python's MRO for multiple inheritance and cooperative method chains, while calling ParentClass.method(self, ...) directly can break in more complex inheritance hierarchies.

An abstract base class defines a required interface that subclasses must implement, and cannot itself be instantiated directly. In Python, you create one by inheriting from abc.ABC and marking required methods with the @abstractmethod decorator. Attempting to instantiate a class that hasn't implemented all its parent's abstract methods raises TypeError: Can't instantiate abstract class with abstract method.

Practice Questions — Test Your Understanding

Work through these before checking the answers. Correctly tracing which class's method actually runs — especially with inheritance and overriding — is the real test here.

1. What is the output of: class Dog: def __init__(self, name): self.name = name \n d = Dog('Bruno') \n print(d.name)

Easy

2. What error occurs, and why, if you run: class Cat: def meow(): print('Meow') \n c = Cat() \n c.meow()?

Easy

3. Trace this: class Animal: def speak(self): return 'generic sound' \n class Dog(Animal): def speak(self): return 'Woof' \n a = Animal() \n d = Dog() \n print(a.speak(), d.speak())

Medium

4. What is the output of: class Counter: count = 0 \n def __init__(self): Counter.count += 1 \n a = Counter() \n b = Counter() \n c = Counter() \n print(Counter.count)

Medium

5. Why does this raise an error? class BankAccount: def __init__(self, balance): self.__balance = balance \n acc = BankAccount(100) \n print(acc.__balance)

Hard

✅ AnswerAttributeError: 'BankAccount' object has no attribute '__balance'. The double underscore prefix triggers name mangling — self.__balance is actually stored internally as self._BankAccount__balance. Trying to access acc.__balance directly from outside the class looks for a plain __balance attribute that doesn't exist under that exact name; you'd need acc._BankAccount__balance to reach it, which is precisely the point of the mangling.

6. What does class Shape(ABC): @abstractmethod def area(self): pass followed by shape = Shape() produce?

Medium

7. What is the output of: class A: def greet(self): return 'A' \n class B: def greet(self): return 'B' \n class C(A, B): pass \n print(C().greet())

Hard

8. What does super().__init__(name, sound='Woof') accomplish inside a subclass's own __init__ method?

Medium

Conclusion — Objects Are a Modelling Tool, Not a Requirement

OOP is genuinely one of the more conceptually dense topics in learning Python, precisely because it isn't just new syntax — it's a different way of thinking about how to structure a program's data and behaviour together. self, __init__, inheritance, and the four pillars all click eventually, usually not from reading a definition but from building a few real classes and watching, first-hand, how an object's state persists and changes across multiple method calls.

If you're a complete beginner, the priority is getting comfortable with the basic mechanics — class, __init__, self, and calling methods on instances — until writing a simple class feels automatic. If you're building real, larger applications, the priority shifts to judgment: recognising when a problem's structure genuinely calls for a class hierarchy versus when a handful of plain functions would be clearer, faster to write, and easier for someone else to follow six months later.

Your Situation	What to Focus On
Learning classes for the first time	✅ class, __init__, self — get the mechanics automatic first
Modelling something with real, persistent state	✅ A class is likely the right tool — bank account, game entity, user session
Simple, stateless data transformation	⚠️ Plain functions are often clearer than an unnecessary class
Sharing behaviour across related types	✅ Inheritance — but keep hierarchies shallow and genuinely justified
Different types need to respond to the same call differently	✅ Polymorphism via method overriding
Need to enforce a required interface for a library	✅ abc.ABC with @abstractmethod
Class is really just holding structured data	⚠️ Consider @dataclass instead of a full manual class
Attribute should have validated, controlled access	✅ @property, not a raw public attribute

The habit worth carrying forward: before reaching for a class, ask honestly whether the problem actually has meaningful, persistent state that needs protecting and behaviour that genuinely belongs bundled with that state — not just because OOP is what you're 'supposed' to use for anything beyond a script. Classes used deliberately, for the problems that genuinely call for them, are one of the most powerful organising tools in the language. Classes used out of habit, for everything, just add ceremony.

OOP in Python is genuinely flexible by design — mostly convention, lightly enforced. Learn the real mechanics behind self and __init__ properly, understand what each of the four pillars actually buys you, and you'll have real judgment about when to reach for a class and when to leave it as a plain function. 🐍

Frequently Asked Questions (FAQ)

__init__ functions similarly to a constructor in languages like Java or C++, running automatically to set up a newly created object's initial attribute values. Technically, the object itself is created by a separate method called __new__, and __init__ only initialises that already-existing object — but for everyday purposes, __init__ is where you write the setup logic that runs when you create a new instance.

Encapsulation (bundling data and the methods that operate on it, controlling direct access), Inheritance (a class reusing and extending another class's attributes and behaviour), Polymorphism (different classes responding to the same method call in their own specific way), and Abstraction (hiding implementation complexity behind a simple, well-defined interface, often enforced with abstract base classes).

What is OOP (Object-Oriented Programming) in Python?

History — How Python's OOP Support Developed

Key Characteristics of Python Classes and Objects

How an Object Gets Created and Used — Flowchart

How OOP Actually Works — self, __init__, and the Error They Explain

🫴 self — Not Magic, Just an Explicit Parameter

💥 The Classic Error — Forgetting self

🔧 __init__ — Setup, Not Creation

The Four Pillars of OOP — Key Differences

OOP Implementation — Python vs Other Languages

Advantages and Disadvantages of Python's OOP Approach

Python's Object Model Architecture

OOP in Practice — From a Basic Class to Inheritance and the Classic Error

Practice This Code — Live Editor

Line-by-Line Explanation

Where OOP Actually Earns Its Place — Real-World Applications

Why OOP Is Worth the Real Effort It Takes

A Closer Look — Encapsulation and Inheritance Patterns

Python OOPs Concepts — Interview Questions

Practice Questions — Test Your Understanding

Conclusion — Objects Are a Modelling Tool, Not a Requirement

Frequently Asked Questions (FAQ)

How OOP Actually Works — self, init, and the Error They Explain

🔧 init — Setup, Not Creation