How Do Classes and Objects Work in Python?

A class is a template; an object is an instance built from it. The class statement creates the template, and calling it creates an object.

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

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


first = Dog("Rex")
second = Dog("Fido")

print(first.bark())          # Rex says woof
print(second.bark())         # Fido says woof
print(first is second)       # False - two different objects

Calling the class runs its __init__ method, which stores the arguments on the instance. Each object has its own instance dictionary, so first.name and second.name are separate values and changing one does not affect the other.

The methods live on the class, not on the instances. Both objects share the same bark function, and the difference in what they return comes entirely from the self reference pointing at a different instance.

Two things about the mechanics are worth knowing. The class itself is an object — a type — and you can inspect it with Dog.__name__, Dog.__mro__ and type(first). And attribute lookup on an instance goes to the instance dictionary first and then to the class, which is the rule that makes class attributes behave differently from instance attributes.

Python allows it. Instances carry a dictionary, and attributes can be added to it at any time.

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


rex = Dog("Rex")
rex.age = 5                       # perfectly legal
print(rex.age)                    # 5
print("age" in rex.__dict__)       # True
print(sorted(rex.__dict__))        # ['age', 'name']

try:
    Dog("Fido").age
except AttributeError as err:
    print("AttributeError:", err)

The attribute was added to that one instance only. A different Dog has no age attribute at all, and reading it raises an AttributeError.

Two things to know about how this works. The attribute lives in the instance dictionary, which you can read directly with __dict__ — that is handy for debugging, and it is how frameworks such as dataclasses and attrs detect fields. And the class is unaffected: if you had written age = 0 in the class body, that would be a class attribute, and setting rex.age would create an instance attribute that shadows it for that object only.

The design question this raises is why Python allows it at all. The answer is that it keeps the language flexible — you can attach metadata to an object at runtime, and it is the mechanism that makes monkey-patching, decorators and many mocking libraries possible. The cost is that typos are not caught until runtime, which is one of the arguments for using __slots__ to restrict the available attributes, or a dataclass to declare them explicitly.

A class is a definition — a blueprint that says what an object of that kind will contain and what it can do. An object is a specific instance created from that blueprint, with its own data.

You define a class with the class keyword, and you create an object by calling the class. Calling it runs the __init__ method with the arguments you supply, and the object is the result.

The class holds the behaviour — the methods, and any class-level attributes shared by all instances. The object holds the per-instance state in its own instance dictionary. That split is why two Dog objects with different names can share the same bark method and still behave differently.

Three related terms worth using precisely. The class itself is an object, and its type is type. An instance is an object of that class, and isinstance checks whether an object is an instance of a class or any of its subclasses. And the type of an instance is not necessarily the class it was created from — it is what type(instance) returns, which is the class unless the class defines __class__.

For an interview, the practical value of the distinction shows up in design. When two classes need to share behaviour, inheritance lets one class reuse the other's methods. When they only need to share data, composition — one object holding another — is usually the better answer, because it avoids the fragile base class problem and keeps the parts replaceable.