Encapsulation — hiding internal state, name mangling (`__name`)

WHAT is Encapsulation?

HOW Python signals "private"

Python has no hard private keyword like Java's private. Instead it uses conventions plus one mild enforcement mechanism (name mangling).

Name Mangling — the one real mechanism

WHY does this exist? (Derive the motivation from scratch)

The purpose is NOT security. It is to avoid accidental name clashes in inheritance.

Consider a Base class with an internal __id, and a Child that also invents an attribute named __id for a totally different purpose. Without mangling, Child.__id would silently overwrite Base.__id and break Base's methods.

HOW mangling solves it: the interpreter renames each one to belong to its own class:

• Base.__id → _Base__id
• Child.__id → _Child__id

They no longer collide — each class's methods quietly refer to their own version.

Worked Example 1 — A self-guarding bank account

class Account:
    def __init__(self, balance):
        self.__balance = 0          # private internal state
        self.deposit(balance)       # go through the guard
 
    def deposit(self, amount):
        if amount < 0:                       # invariant check
            raise ValueError("no negatives")
        self.__balance += amount
 
    def get_balance(self):
        return self.__balance

a = Account(100)
print(a.get_balance())   # 100
a.__balance              # AttributeError!
print(a._Account__balance)  # 100  <- the mangled name

• Why self.__balance inside __init__? Why this step: writing __balance triggers mangling, so it actually stores _Account__balance. Outsiders typing a.__balance look for a non-existent attribute → AttributeError. The invariant (balance >= 0) can only be changed via deposit.
• Why does a._Account__balance work? Why this step: mangling only rewrites code inside the class body. From outside you can type the mangled name literally — proving this is not security, just clash-avoidance.

Worked Example 2 — Mangling preventing inheritance collision

class Base:
    def __init__(self):
        self.__data = "base secret"     # -> _Base__data
    def reveal(self):
        return self.__data              # compiled as self._Base__data
 
class Child(Base):
    def __init__(self):
        super().__init__()
        self.__data = "child stuff"     # -> _Child__data (different!)
    def reveal_child(self):
        return self.__data              # self._Child__data

c = Child()
print(c.reveal())        # "base secret"  <- Base's data intact!
print(c.reveal_child())  # "child stuff"
print(c.__dict__)        # {'_Base__data': ..., '_Child__data': ...}

• Why doesn't Child.__data clobber Base.__data? Why this step: each __data was mangled at compile time using the class it was written in, giving two distinct keys. This is the whole point of mangling.

Worked Example 3 — Properties: the Pythonic way to hide

Name mangling protects internal names, but the idiomatic way to expose controlled access is @property.

class Temperature:
    def __init__(self, celsius):
        self._celsius = celsius           # single underscore: "internal"
 
    @property
    def celsius(self):                    # getter
        return self._celsius
 
    @celsius.setter
    def celsius(self, value):
        if value < -273.15:               # invariant: above absolute zero
            raise ValueError("below absolute zero")
        self._celsius = value
 
    @property
    def fahrenheit(self):                 # computed, read-only
        return self._celsius * 9/5 + 32

• Why a property and not a public attribute? Why this step: t.celsius = -300 now runs the setter and is rejected, protecting the invariant — while callers still use clean t.celsius syntax (no ugly get_/set_).
• Why is fahrenheit read-only? Why this step: no setter defined, so assigning raises AttributeError; it's derived state and shouldn't be stored independently.

Common Mistakes (Steel-manned)

Flashcards

Connections

• OOP Fundamentals
• Abstraction — hiding complexity behind interfaces
• Inheritance — base and derived classes
• Properties and Descriptors
• Class Invariants & Validation
• Access Modifiers (Java vs Python)

Concept Map

Hinglish (regional understanding)